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PURPOSE OF THIS MANUAL 


This publication presents a hypothetical mailing list 
application that illustrates how you design and 
implement application programs on System/38. Various 
approaches to the applications are shown, starting with 
batch type processing and progressing to interactive 
type processing. Because these approaches are 
designed to teach you how to use various System/38 
functions, they may not be practical for your use and 
may vary from the approaches presented in System/38 
customer classes. 


Note: The chapters should be read in sequence 
because the information presented assumes that you 
have an understanding of the previous chapters. 


ORGANIZATION OF THIS MANUAL 


This publication is divided into eleven chapters and three 
appendixes: 


Chapter I gives an overview of this publication, 
introduces the mailing list application, and summarizes 
the various application approaches described in this 
publication. 


Chapter 2 introduces basic System/38 functions and 
operations that are used or assumed to be available in 
subsequent chapters. 


Chapter 3 describes an approach that uses diskettes to 
enter data for printing mailing labels. 


Chapter 4 describes an approach that uses diskettes to 
enter data for updating a master file and for printing a 
maintenance report as well as mailing labels. 


Chapter 5 describes various system functions that are 
performed from the work station. 


Chapter 6 describes how to use and create libraries and 
files on the System/38 and in the application. 


Chapter 7 describes an approach to interactively enter 
data for the application and then apply those changes in 
a batch manner to the master file. 
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Chapter 8 describes several ways to interactively enter 
and maintain data for the application, use multiple 
access paths, and selectively display records. 


Chapter 9 describes an approach in which the master 
file is updated by multiple batches of transactions from 
diskettes. 


Chapter 10 describes an approach that allows work 
station users to enter new batches of transactions while 
completed batches are being applied to the master file. 


Chapter 11 describes an approach that allows multiple 
work station users to apply immediate updates to the 


master file without interferring with one another. 


Appendix A discusses multiple libraries and shows how 
to use them in the application. 


Appendix B discusses a series of user-written menus 
that could be used in the application. 


Appendix C presents an alphabetic list of the field 
reference file field names. 
CONVENTIONS 


Blank lines are occasionally used in the data description 
specifications and RPG specifications to improve clarity. 


Many of the figures that depict programming 
components are presented from a conceptual viewpoint 
and are not intended to represent actual implementation. 
Some words are printed entirely in uppercase. These 
include names of files, libraries, objects, queues, 


subsystems, and commands. 


He means he or she. 
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SUMMARY OF CHANGES 
The following major changes have been made: 


e The publication has been reorganized to place the 
discussion of each application approach in a separate 
chapter. 


« An illustrated summary of the various application 
approaches described in the publication has been 
added (Chapter 1). 


« All examples of the source entry utility, data file 
utility, and query utility have been updated (Chapters 
5, 7, and 8). 


« An example of using the screen design aid has been 
added (Chapter 8). 


Because of these extensive changes, the publication 
should be reviewed in its entirety. 


WHAT YOU SHOULD KNOW 
Before reading this publication, you should: 
¢« Be able to write application programs using RPG. 


e« Read the IBM System/38 Introduction, GC21-7728, 
and IBM System/38 Control Program Facility 
Concepts Manual, GC21-7729, or have an equivalent 
level of knowledge (including System /38 
terminology). 


IF YOU NEED MORE INFORMATION 


The following manuals contain additional information on 
the functions and procedures described in this 
publication, and help you determine where to look for 
that information. 


vi 


CPF (Control Program Facility) Commands and 
Functions 


IBM System/38 Control Program Facility 
Programmer's Guide, SC21-7730 

— Creating control language programs 
— Using program variables 

— Invoking programs 

— Using data base files in programs 

— Access paths 

— Using DDS to describe files 

— Creating a physical file 

— Creating a logical file 

— Creating a field reference file 

— Creating a source file 

— Creating a display file 

— Overriding files 

— Copying files 

— Using data base logging in recovery 
— Creating user profiles 

— Saving/restoring objects and libraries 


IBM System/38 Control Language Reference Manual, 

$C21-7731 

— Control language syntax and syntax diagrams 

— Details on all parameters of control language 
commands 


IBM System/38 Control Program Facility Reference 

Manual—Data Description Specifications, SC21-7806 
— Referencing previously defined fields 

— Specifying record formats 

— Specifying key fields 

— Specifying select/omit fields 

- Specifying DDS keywords 


IBM System/38 Programmer’s/User’s Work Station 
Guide, SC21-7744 

— Signing on and off a work station 

— Interacting with displays 

— Using command entry and prompt facilities 

— Using the programmer menu 

— Using the program call menu 

— Handling messages from a work station 











« IBM System/38 Operator’s Guide, SC21-7735 
— Starting the system 
— Using the system operator menu 
— Submitting batch jobs through spooling 
— Submitting batch jobs from work stations 
— Handling readers and writers 
— Handling job queues and output queues 
— Handling spooled output files 
— Saving/restoring objects, libraries, and the system 
(procedures) 


e IBM System/38 Problem Determination Guide, 
SC21-7876 
— Procedures for resolving problems with jobs or the 
system 
— Recovering from an abnormal termination 


IBM System/38 Guide to Program Product Installation 
and Device Configuration, GC21-7775 

— Installing CPF 

— Installing languages and utilities 


Languages and Utilities 


e IBM System/38 RPG III Reference Manual and 
Programmer's Guide, SC21-7725 
— Coding RPG specifications 
— Considerations in specifying file descriptions 
— Using RPG indicators 
— Using operation codes 
— Using the CALL/RETRN function 
— Application design 
— Creating and executing RPG programs 


e IBM System/38 Data File Utility Reference Manual 
and User’s Guide, SC21-7714 
— Using DFU displays to create or change an 
application 
— Executing an application using the execution menu 
— Executing an application by entering a command 
— Managing existing applications 


¢ IBM System/38 Query Utility Reference Manual and 
User’s Guide, SC21-7724 
— Using query displays to create or change a query 
application 
— Executing a query 
— Considerations in query design 
— Managing existing applications 


e IBM System/38 Screen Design Aid Reference Manual 
and User's Guide, SC21-7755 
— Using SDA displays to create a menu 
— Using SDA displays to create a display record 
format 
— Using SDA displays to test an existing display 
record format 


e IBM System/38 Source Entry Utility Reference Manual 
and User’s Guide, SC21-7722 
— Using SEU displays to enter and change source 
— Using line commands on the edit display 
Content and Use of System/38 Publications 
e IBM System/38 Guide to Publications, GC21-7726 
— Contents of System/38 publications 
— Reading sequences for System/38 publications 
e IBM System/38 Glossary and Master Index, 
GC21-7727 
— Index entries from frequently used System/38 
publications 
— Glossary of terms used in System/38 publications 
OTHER MATERIALS USED 
The following materials are used in this publication: 
e IBM System/38 Keyboard Template, GX21-7756 


e IBM Data Description Specifications, GX21-7754 


e IBM RPG Control and File Description Specifications, 
GX21-9092 


e IBM RPG Extension and Line Counter Specifications, 
GX21-9091 


e IBM RPG Calculation Specifications, GX21-9093 
e IBM RPG Input Specifications, GX21-9094 
e IBM RPG Output Specifications, GX21-9090 


e IBM Data Description Specifications Debugging 
Template, GX21-7717 


e IBM Printer /Display Layout, GX21-9174 
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Chapter 1. Introduction 


OVERVIEW OF PUBLICATION 


This publication presents various design approaches to an application to help 
you understand designing and implementing application programs on 
System/38. A mailing list application is used because it is simple in concept 
and yet it contains many of the basic requirements of any application. 


This chapter introduces the mailing list application and summarizes various 
design approches to implementing the application. These various approaches 
and the functions used in them are described in subsequent chapters of this 
publication. 


The discussion in each subsequent chapter assumes a knowledge of the 
previous chapter. Therefore, the chapters should be read in sequence. 
System/38 functions are introduced as they are needed for a particular 
application approach. Some chapters are devoted entirely to a discussion of 
functions to be used in subsequent chapters. 


The best way to use this publication is to try the approaches on your system 


with your data (see the additional details under Summary of Application 
Approaches later in this chapter). 
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MAILING LIST APPLICATION 





This mailing list application allows you to create and maintain a mailing list file 
(called a master file), and to print mailing labels from the file. 


Characteristics 


Each mailing list record in the master file has the following format: 
Mailing List Record 


Length Position | Decimal 
Field Description | Field Name | (characters) | Range Positions | Field Type 


Account number |ACTNUM Numeric 


Type of account | ACTTYP 1 Numeric 
Name NAME ~_ Character 
Address ADDR Character 
City CITY Character 
State STATE Character 
Zip Code ZIP Numeric 











The account number (ACTNUM) is unique for each record. The account type 
(ACTTYP) can be any of the following values: 


ACTTYP Field 


Business 





Government 


Organization 


School 





Private 


Other 





A typical mailing list record might look like this: 


ACTNUM ACTTYP NAME Crry STATE ZIP 


10522 ae JJ JOHNSON | 489 WHITNEY ST |CHICAGO 





You maintain the master file by adding, deleting, and changing the mailing list 
records. When printing a mailing list from the master file, you can use various 
selection criteria to select particular types of records and to arrange the records 
in various sequences. For example, a mailing list printout might include: 


e All government accounts in New Jersey. The list would be printed in 
numeric sequence by account number within zip code areas. 


e All school and private accounts in a specific zip code area. The list would 
be printed in alphabetic sequence by name. 


e All records in account number sequence within zip code areas. 


Although this application is simple, its requirements are typical of many data 
processing applications: 


e It has a master file. 

e Transactions are applied to the master file (maintenance of the file). 
e The data is printed in various sequences. 

e There can be multiple work station users. 


e Backup of files and programs must be considered. 
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Naming Rules and Conventions 


General 


System/38 requires you to assign names to libraries, programs, and files. In 
addition to naming rules established for System/38, you may want to establish 
your Own naming conventions to help you organize your application. No single 
set of naming conventions is the best; your naming conventions should be 
easy for you to use and understand. 


Some System/38 naming rules to remember are: 

e Objects of the same type within a specific library must have unique names. 

¢ Members of a specific data base file must have unique names; however, a 
member name can be the same as a program or file name within the same 
library. 


¢ Fields within a specific record format must have unique names. 


¢ RPG Ill requires that all file, record, and field names be unique within a 
program. 


For more naming rules, refer to the Control Language Reference Manual and the 
RPG ill Reference Manual and Programmer's Guide. 





For the Mailing List Example 
In this mailing list example, the following naming conventions are used: 
e Object names begin with MLG for mailing (such as MLG310). 


« Physical file names are 7 characters, the last of which is P (such as 
MLGMSTP). Record format names for the files are 7 characters, the last of 
which is R (such as MLGMSTR). 


e Logical file names are 7 or 8 characters, the seventh of which is L (such as 
MLGMSTL); if there is an eighth character, it is a digit (such as 
MLGTRNL1). 


e Program names are 6 or 7 characters; the first 3 are MLG, the second 3 are 
digits, and the seventh, if present, is C for control language (CL) programs, 
U for DFU programs, and Q for Query programs. The digits designate the 
program type as follows: 


000-029 Initial menu 

030-099 Logical function menu 
100-199 Data entry 

200-299 Inquiry 

300-399 Maintenance 

400-499 Update 

500-699 _ Basic analysis 

700-899 Monthly/yearly analysis 
900-999 One-time program 


RPG IIl program names are 6 characters (such as MLG105). CL, DFU, and 
Query program names are each 7 characters (such as MLGO35C, MLG315U, 
and MLG9100 respectively). 


e Display file names are the name of the program with which they are 
associated plus D (such as MLG105D or MLGO35CD). 
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System Requirements 


The application requires that you have any model of the System/38 plus the 
following: 


© IBM 5211, 3262, or 3203 Printer 
« IBM 5251 Display Station Model 11 or 12, or equivalent 


« Offline device (such as an IBM 5280 Distributed Data System) to create files 
on diskettes 


- Program products: 
— Control Program Facility (Program 5714-SS1) 
— RPG Ill (Program 57714-RG1) 
— Interactive Data Base Utilities (Program 5714-UT1) 


- Disk storage sufficient for: 

The machine product 

The program product 

Objects created for the application 
Data required for the files 


For information on describing the devices to the system and installing the 
program products, refer to the Guide to Program Product Installation and Device 
Configuration. 








Additional Considerations 


For the examples in this publication, programs are often simplified by using the 
system defaults for file and library names, queues, and system functions. For 
an explanation of the defaults, refer to the appropriate command in the Control 
Language Reference Manual. 
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SUMMARY OF APPLICATION APPROACHES 


Each application approach in this publication provides a different example of 
how to use a combination of System/38 functions to implement the mailing 
list application. The examples begin with a simple batch approach that uses a 
basic set of System/38 functions and progress to sophisticated batch and 
interactive approaches that use most of the System/38 functions. Each new 
approach builds on the previous approaches. 


You can use these approaches as an effective learning tool by actually 
following through the steps of creating the example files and programs on your 
system. You can also observe the results of the application approaches by 
executing them on your system, using actual or sample data (names, 
addresses, account numbers, and so on) of your own. 


The approaches in Chapters 3 and 4 require an offline device, such as the 
5280 Distributed Data System, to enter the instructions and data on diskette. 
If such an offline device is not readily available, you may want to start at 
Chapter 5; however, Chapters 2 through 4 should be read first because they 
introduce concepts used in later chapters. The procedures and approaches 
described in Chapters 5 through 8 can all be done at a work station. 


Chapters 9 through 11 describe approaches that use advanced techniques. 
You can also execute these approaches on your system if you choose. To 
execute the approach in Chapter 9, you will need an offline device to enter the 
data on diskettes. The approaches in Chapters 10 and 11 are executed at a 
work station. 


The following summarizes the approaches and how they relate. 











Simple Batch Input (Chapter 3) 


In this first approach, master records (names and addresses) are keyed onto 
diskette at an offline device. These master records are then read from diskette 
into the system, and an RPG Ill label printing program prints the records as 


mailing labels. 





Call Label Printing Program 










Printing 
Program 
















Mailing 
Labels 





AAAI) 
WOT 


Chapter 2 describes the basic system functions that are used in this approach. 
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Batch Input and Batch Maintenance (Chapter 4) 


This approach is an extension of the previous approach (Chapter 3). Instead of 
being read from diskette, the master records are stored in the system in a data 
base master file. Transaction records for updating the master file are keyed 
onto diskettes at an offline device. These transaction records are then read 
from diskette, and an RPG lil maintenance program updates the master file 
with the transaction records. The maintenance program also produces a report 
of changes to the master file. 


Call Maintenance Program 











Transactions 








Maintenance 
Program 






Report of 
Changes 


Report of Changes 







To Printer 














After the master file has been updated, an RPG Ill mailing list program 
produces a mailing list from the updated master records. 





Mailing 
List 





Mailing 
List 
Program 










Mailing List 











To 
Printer 





The RPG III programs and the master file are created from source that is read 
from diskette. 


introduction 


bh 


Interactive Input and Batch Maintenance (Chapter 7) 


In the previous approach (Chapter 4), transactions to update a master file were 
read from diskette. In this approach, a work station user enters transactions 
interactively through a data file utility (DFU) application. The entered 
transactions are stored temporarily in a data base transaction file. 









DFU 
Application 






Transactions 








Trans- 
action 
File 






Transactions 

















An RPG III maintenance program then applies the transaction records from the 
transaction file to the master records in the data base master file. 

















Trans- IY. 
action ; 
Transactions 


File 





Maintenance 
Program 





FLD 


Call Maintenance 
Program 





The maintenance program also produces a report of changes. 


The DFU application, the RPG program, and the data base files are all created 
from a work station in this approach. The discussion of this approach assumes 
that you have previously read Chapters 5 and 6, which describe how to use the 
programmer menu and the source entry utility (SEU) to create files, libraries, 
and programs. 
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Interactive Input and Interactive Maintenance (Chapter 8) 





In the previous approach (Chapter 7), a work station user interactively entered 
transactions into a transaction file, and the batch of transactions was then 
applied to the master file by a maintenance program. This approach allows 
multiple work station users to interactively update the master file itself through 
a DFU application. 









DFU 
Application 















Mailing List ao 
Clerk Menu / / 
Option 14 
Option 2 
Option 30 











Several ways of calling the DFU application for this approach are described: 


« A work station user enters the control language command that directly calls 
the application. 


e A work station user calls a control language program by entering the 
program name on a general user menu (the program call menu). The 
program then calls the DFU application. 


« At sign-on, a work station user receives a specialized menu that is provided 
by a control language program and an associated display file. When the 
user selects a specific option on the menu, the control language program 
calls the DFU application. 


Also included in this approach are two methods of making an inquiry into the 
master file: 


¢« Using a DFU application that examines specific fields of the master file 
through a separate access path. 


e Using a query application that produces a report on specific fields of the 
master file. 
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Batch Maintenance of Multiple Diskette Batches (Chapter 9) 


This approach extends the approach of Chapter 4 so that transactions on 
multiple diskettes can be handled in a single operation. 


Batches of transactions are keyed onto diskettes at one or more offline 
devices. A control language program sequentially copies the data from each 
diskette into a data base file, and the resulting sequential arrangement of data 
in the file creates an input stream of batch jobs. The program then starts a 
spooling reader to read the input stream from the data base file. When each 
batch job in the input stream is executed, an RPG III maintenance program is 
called to apply the transaction records to a data base master file. 














Diskette Data 








Job 
Transactions 








Diskette 
Copy 
Program 









// Job 
Call Maintenance Program 


e 
Transactions 





Transactions 





Maintenance 
Program 


Update 


Call Copy 
Program 
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Batch Maintenance of Multiple Work Station Entries (Chapter 10) 


In Chapter 7, a work station user entered transactions into a transaction file, 
and a maintenance program then applied the transactions to a master file. Only 
one work station user could enter transactions at a time. The approach in this 
chapter allows one or more work station users to enter new batches of 
transactions at the same time that completed batches are being processed. 


An RPG Ill program and an associated display file provide the displays on 
which the work station users enter individual batches of transactions. The 
displays are formatted so that each work station user entering transactions 
provides a batch number (which identifies the batch) and indicates when the 
batch is complete. Header records that identify the batches of transactions and 
their status are stored in a batch header file. The transaction records being 
entered are stored in a transaction file. A logical file provides access to both 
the header information and the transaction records. 









Transaction 
Entry 
Program 






Batch ID/Status 









Trans- 
action 
File 






Transaction Batch Transaction Batch 
Ls 














This approach assumes that a maintenance program similar to that in Chapter 
7 will be used to apply the transaction records to the master file. Only batches 
whose header record indicates a status of complete are applied to the master 
file. 


Header 
File 
Batch Complete 












Trans- 
action we 


File Transactions 


a 





Maintenance 
Program 


I 


Call Maintenance 


Yf 
a 
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Interactive Maintenance from Multiple Work Stations (Chapter 11) 


This approach is a more sophisticated version of the interactive maintenance 
approach in Chapter 8. Multiple work station users can: 


« Add records to the master file. 

e Change records in the master file. 

« Delete records from the master file. 
« Display records in the master file. 


These functions are provided through an RPG III program and an associated 
display file. 
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The RPG III display/update program also produces a report of changes. 
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Chapter 2. Basic Functions and Operations 


OVERVIEW 


This chapter introduces some basic System/38 functions and operations that 
are used or assumed in the application approaches. Topics discussed include: 


e« Basic functions 

— Interactive and batch jobs 

— Input/output spooling 

— Subsystems 

— User profiles and passwords 
e System installation 


e Preparing for daily operations 


e General recovery considerations 
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BASIC FUNCTIONS 


System/38 can support a range of environments from one consisting almost 
entirely of batch processing to one that makes extensive use of interactive 
processing through work station applications. System/38 allows you to select 
and combine techniques from various approaches. The basic functions of 
System/38 to be used in the following chapters are introduced here. More 
detailed discussions of these concepts are in the CPF Concepts Manual. 


Interactive Jobs 


An interactive job is a job in which the processing actions are performed in 
response to input provided by a work station user. During the job, a dialog 
exists between the user and the system. 


An interactive job starts when you enter your password at the work station or 
system console and ends when you sign off. Commands or application 
functions can be entered during an interactive job. Menus, prompts, and 
messages Can assist you in interactively responding to the System/38. 


Sign Off 
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Batch Jobs 


A batch job is a group of processing actions submitted as a predefined series 


of actions, such aS commands, to be performed without a dialog between the 
user and the system. 


A batch job is first placed on a job queue and then selected for execution by 
the CPF. One method of placing jobs on a job queue is spooling. 
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Spooling 


System/38 provides both input spooling and output spooling. Input spooling 
takes the information from an input device and places jobs on an input job 
queue. Output spooling allows programs to write to a spooled output file 
rather than directly to an output device. This spooled output file is placed on 
an Output queue and written to an output device at a later time. 


For input spooling, a CPF program called a reader transfers jobs from an input 
device to a job queue. The jobs read by the reader are an input stream. An 
input stream is a group of records submitted as batch input that contains 
control language (CL) commands for one or more jobs and, optionally, the data 
records of one or more inline data files. An inline data file is a data file 


included with a job when the job is read from an input device by a reader 
program. 


All printed output is normally spooled. Spooling can allow multiple print jobs to 
execute simultaneously even if all of the jobs use the same printer. A CPF 


program, called a writer, transfers spooled output files from an output queue to 
an output device, such as a printer. 
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Job Queues 


Batch jobs submitted to the system for processing are placed on a job queue, 
which is an ordered list of jobs in storage waiting to be executed. A typical 
way to place jobs on the queue is to have the system operator start a reader, 
such as a diskette reader. The default job queue for a start reader command is 
QBATCH. As shown in the following illustration, each job on a diskette file 
becomes a separate entity on a job queue. Inline data, if present, is stored in 
spooled inline data files, which are created automatically by the spooling 
function. Jobs are selected from the job queue for execution and, after 
execution, the associated spooled input files are automatically deleted. 
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Printed Output 


The several types of System/38 printed output include the following: 
« QOutput from a printer file in an RPG III application program 


« Qutput from a system function, such as the source listing of the RPG II! 
compiler 


« Qutput from CPF, such as the fob log, which lists commands executed as 
part of the job and the associated system responses 


Printed output is directed to a printer device file, which connects the program 
to a spooled output file. The spooled output file derives its name and attributes 
from the device file. A spooled output file contains output records that are 
waiting to be printed. For each spooled output file, an entry is placed on an 
output queue. 


For this application example, the default printer device file and the default 
output queue are IBM-supplied and both are named OPRINT. 


The spooled output files are stored until printed. After being printed, the files 
are automatically deleted. 
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Subsystems 


Subsystems provide an operating environment for work performed within them. 
A job must be assigned to an active subsystem before any processing for the 
job can take place. A group of jobs that have common characteristics can be 
controlled independently of other jobs if the jobs are assigned to the same 
subsystem. All subsystems have the same basic capabilities, but they may be 
defined to operate on a specific type of work. Four of the |BM-supplied 
subsystems, shown on the following page, are used in the application 
approaches in this publication. These subsystems are as follows: 


e QSPL is for both input and output spooling operations and is usually started 
by the system operator. The system operator must also start readers and 
writers that operate in this subsystem. 


e QBATCH is for batch operations and is usually started by the system 
operator. The job queue on which jobs are to be placed for processing in 
this subsystem is also named QBATCH. 


e QCTL is for interactive work and is the controlling subsystem. It is started 
automatically when the system is powered on. When only QCTL has been 
started, the system console is the only device that you can use. 


e QINTER is for interactive work and is usually started by the system 
operator. Normally, work stations such as the 5250 series of display 
stations are used with this subsystem. 





The illustration shown here is a simplification of subsystem usage. Although 
not shown in this illustration, interactive jobs can also place jobs on a job 
queue and place output files on an output queue. 
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User Profiles and Passwords 


System/38 supports various security functions to help protect the system 
against improper use. These functions are based on user profiles and 
passwords. A user profile is an object that represents a particular user or group 
of users to the CPF and identifies which objects and commands the user is 
authorized to use. CPF is shipped with several IBM-supplied user profiles, 
each of which has a password. A password is a name that a system user 
enters at the console or a work station to identify himself to the system. 


The basic user profiles that are shipped with CPF and used in this publication 
are listed below: 


User Profile 
System User Name Password 
Programmer OQPGMR PGMR 
System Operator OSYSOPR SYSOPR 
Work Station User QUSER USER 
Security Officer QSECOFR SECOFR 


Many users can operate under the same user profile. In addition to the user 
profiles listed above, the security officer can create user profiles for individuals 
or departments to allow better control. 


The IBM-supplied profiles (including the passwords) can be modified and new 
profiles can be added by using the System/38 security functions. An example 
of adding a new profile is given in Chapter 8 under Using a User Profile and an 
Application-Oriented Menu. 











INSTALLING YOUR SYSTEM 


To use System/38, you must install the program products and describe the 
hardware configuration to the system. The procedure to do this is given in the 
Guide to Program Product Installation and Device Configuration. 


System /38 offers a variety of options for specializing your system. For the 
mailing list application in this publication, none of these options are selected; 
only the basic requirements as described in the Guide to Program Product 
Installation and Device Configuration are selected. 


PREPARING FOR DAILY OPERATIONS 


The application approaches discussed in this publication assume that you or 
your system operator have prepared the system for daily operations. The 
procedures involved are briefly discussed here. For a complete discussion of 
these procedures, refer to the System/38 Operator’s Guide. 


The system is powered on from the operator/service panel. Powering on 
causes the CPF start-up process to begin. The sign-on display appears first 
on the system console screen. The cursor is automatically positioned for you 
to enter a password: 


Enter password to sign on: 





Note that your password does not appear on the screen as you key 
it in (so that no one can see the password you are using). 
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Normally, the system operator's password, SYSOPR, is entered. Next, the start 
control program facility prompt appears: 


START CONTROL PROGRAM FACILITY PROMPT 
Enter the following: 

System date (MDY): ll 7 17 7 80 
System time: 00 : 
Job queues (*KEEP *CLEAR): #KEEP 
Output queues (*KEEP *CLEAR): *¥KEEP 
Incomplete job logs (*KEEP *CLEAR): KEEP 
Configuratton menu (*NO *YES): *NO 
Data base recovery wart 

(¥NO *YES): ¥NO 


Last termination was NORMAL 





© Verify that this is the current date. 


© Enter the current time. 


The system uses the defaults unless you change them. Normally, you just 
verify the date and enter the current time. 


During the CPF start-up, the QSYSGPR (system operator message queue} 
display may appear one or more times on the system console screen to show 
messages regarding the status of the system and system equipment. 











If the system operator password was entered on the sign-on prompt, as in this 
application example, the system operator menu is displayed when the CPF 
start-up process is completed. The menu allows you to perform various 
operations by selecting one of the options listed on it. In this application 
example, you select the option that allows you to execute a command. 


Because you will need to use the QBATCH subsystem, you enter the Start 
Subsystem (STRSBS) command: 


SYSTEM OPERATOR MENU 
Select one of the following: 
1. DSPJOBQ ( jobq) . STRPRTWTR device,outq 
2. DSPOUTQ (outq) » CNLWTR writer 
3. SNDOMSG tomsgq,(type)smsg STRDKTRDR device, label 
4. CALL program. . CNLRDR reader , 
_ Execute command SIGNOFF (#*NOLIST *LIST) 
“SBMJ0B Cjob); (jobd), (cmd) 


ii ‘Option: 5 Parma: —— en: 
Msg or emd: strsbs sbsdighatch) G@—S—C—CSC<‘(; OU 


Log requests: YES CF3-Command entry CF4-Prompt (5 only} 
CF6-DSPMSG QSYSOPR CF7-DSPSBS CF8-DSPSYS 





& Specify option 5 to execute a command. 


B Enter the command here. 


Note that the alphabetic characters you enter appear as lowercase because the 
keyboard is normally in lower shift. The system will accept either uppercase or 
lowercase for most command functions. 


Other subsystems you will need to use are QSPL and QINTER. When the 
system operator menu is displayed again with the option field blank, you use 


option 5 again to separately enter the following commands: 


strsbs sbsd(qspl) 
strsbs sbsd(qinter) 
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A printer writer also needs to be started to the device QSYSPRT from the 
Output queue QPRINT. You enter the Start Printer Writer (STRPRTWTR) 
command by selecting option 7: 


SYSTEM OPERATOR MENU 
Select one of the following: 
» DSPJOBQ ( jobq) - STRPRTWTR device,outg 
- DSPOUTQ foutq) . CNUNTR uriter 
- SNDHSG tomsgqs( type)» msg - STRDKTRDR device;label 
» CALL program . CNLRDR reader 
. Execute command - SIGNOFF (¥NOLIST *LIST) 
. SBHJOB ( job) sf jobd))¢emd) 


Option: 7. Parms: gsvsprt-@ gprint © 


Msg or cmd: 


eee 
Log requests: *YES CF3-Command entry CF4-Prompt (5 only) 
CF6-DSPMSG QSYSOPR CF7-DSPSBS CF8-DSPSYS 





A) Specify here the name of the device on which the Output is to be printed. This 
device name is also used as the name of the writer. 


© Specify here the name of the output queue from which the output is to be printed. 


Now your system is ready for the approaches described in this publication. 


During the day, you may want to check on the status of a particular job or a 
spooled output file from a job. The commands and displays you can use to 
determine the status of jobs and spooled output files, or to change their status, 
are described in detail in the System/38 Operator’s Guide. If you have a 
problem with the operation of the system, you may want to refer to the 
System/38 Problem Determination Guide. 


When your system is ready to be powered down at the end of the day, select 
option 5 on the system operator menu and enter the Power Down System 
(PWRDWNSYS) command. This will properly terminate the system and turn 
off the power. 








Cc 


GENERAL RECOVERY CONSIDERATIONS 


Recovery must be considered in any application design. There are many 
different recovery situations; however, these situations can generally be 
categorized as follows: 


¢ incorrect data is usually caused by human error, such as entering data 
incorrectly, not executing a program when it should be, or using a program 
that contains an error. These error situations are common and normally 
corrected by obvious solutions, such as reentering correct data, executing a 
program, or correcting a program. 


¢ System failure can occur for various reasons, such as electrical power 
interruptions, and requires restarting the system. In most system failures, 
data on auxiliary storage remains usable. Data which Is in main storage at 
the time of the failure will be lost. To avoid losing updates to data base 
files, the FRCRATIO parameter may be specified on the Create Physical File, 
Create Source Physical File, Create Logical File, and Override with Data 
Base File commands; however, there is some performance degradation 
when a value is specified for FRCRATIO. System/38 has some built-in 
recovery functions which, for example, properly close files and ensure that 
the data for the file is in auxiliary storage. To recover from a system failure, 
you must either restart or reprocess what was happening when your system 
failed. |f a system failure occurs when you are not executing an application 
(such as when no programs are executing), no recovery is normally needed. 


« Damage is the condition of any object that can no longer be processed by 
the system (such as when a disk has been physically damaged). Although 
an object is unlikely to become damaged, recovery must be considered. To 
recover a damaged |IBM-supplied object, you must delete and restore the 
object, or restart the system, or install the system again. To recover a 
damaged user-defined object, you normally restore a saved version or 
create the object again. 


The basic System/38 recovery support is the Save/Restore functions, which 
allow you to save backup versions of current objects on diskette or tape and to 
restore these objects as needed. Backup is essential to any application 
approach. How often you save your objects and which objects you choose to 
save varies with the application. There is no general recovery approach that is 
best for all applications. You should consider various trade-offs (such as the 
cost to frequently save objects versus reprocessing time) and risks (such as the 
probability of power interruption and fire) when developing your recovery plan. 


There are comments on recovery throughout the remainder of this publication. 


These comments are not intended to be complete approaches to a recovery 
situation, nor are they the only approach to a particular recovery situation. 
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Chapter 3. Simple Batch Input 


OVERVIEW 
In this first approach to the mailing list application: 


« An input stream consisting of job instructions (CL commands) and data 
(master records) is entered on diskette at an offline device. 


« The input stream is read from diskette and placed in system storage. An 
inline data file is created to store the master records. 


e A CALL command within the job instructions invokes an RPG III label 
printing program. 


e The program reads the inline data file containing the master records and 
prints the master records as mailing labels. 


The label printing program used in this approach is also created from an input 
stream that is read into the system from diskette. 









Label Printing 
Program 
MLG520 


QPRINT 


The records are printed in the same sequence as they are read. The master 
records are not stored or updated on the System/38 in this approach. This 
approach is used to introduce and illustrate some System/38 functions, even 
though it may not meet the needs of many installations. 





Master Records 
(names and 
addresses) 
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LABEL PRINTING PROGRAM 


An RPG III label printing program named MLG520 is used to read the records 
from the inline data file, INPUT, and print a mailing label for each record using 
the printer device file, QPRINT. The program can execute with either spooled 
or nonspooled input or output data. Generally, the program is not aware of 
where the input data comes from or where the output data is placed. The 
program specifies the files INPUT and QPRINT so that: 


> An input file (INPUT) will normally come from an inline spooled data file 
(identified by the // DATA statement in the input stream). 


¢ Output is normally written to a spooled output file (QPRINT), which is 
placed on the QPRINT output queue for later writing to a device. 


Specifications for the Label Printing Program 


The MLG520 program uses the RPG program cycle to read and print mailing 


list records. 


The control and file description specifications for MLG520 are shown in Figure 
3-1. 
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Figure 3-1. Control and File Description Specifications for MLG520 Label Printing Program 
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GX21 9092. UM 050° 





2 


No entries are required in the control specifications. RPG III will default to 
standard values. 


In the file description specifications, the first three lines are comments (* in 
position 7 designates a comment). The text in the second comment line 
identifies the source to the programmer. 


The file names (positions 7 through 14) are the names of device files, data 
base files, or inline data files that are defined in the system. INPUT is the 
name of an inline data file, which is the master file. The diskette record length 
is specified as 128 bytes, which is the length of the basic data exchange 
format on diskette. QPRINT is the name of an IBM-supplied printer device file. 
Each spooled output file produced by the MLG520 program derives its name 
and attributes from this QPRINT device file. 


The device names (positions 40 through 46) are used by the RPG III compiler 
to determine the valid language functions that can be specified for the file. The 
device names do not determine which device will be used. For example, the 
device name SEQ specifies a sequential device. This means the file is read or 
written without special device characteristics, such aS space, skip, CHAIN, or 
SETLL. The device name PRINTER specifies a printing device, and entries for 
space or skip are valid. 


The input specifications, shown in Figure 3-2, define the input fields for INPUT 
and identify the input record with indicator 01. The characters AA in positions 
15 and 16 specify that the program is not to check the sequence of input 
records. 
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Figure 3-2. Input Specifications for MLG520 Label Printing Program 
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The output specifications, shown in Figure 3-3, define the four lines to be 
printed on each label. The format of the printed labels is shown in Figure 3-4. 
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Figure 3-3. Output Specifications for MLG520 Label Printing Program 
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Spacing entries cause the printer to move from one label to the next. The OF 
indicator is specified on the file description specifications (see Figure 3-1) even 
though no overflow line is specified on the output specifications. The OF 
indicator must be specified; otherwise, RPG causes a default overflow. The 01 
indicator in positions 24 and 25 identifies the output record. 


The output from the program will be written to the QPRINT spooled output 
file. 


Label Printing 
Program Output File 
OPRINT 
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Creating the Label Printing Program 


The label printing program MLG520 to be used in this approach must be 
created first. One way to create the program is from an input stream. An input 
stream is a group of records submitted to the system as batch input that 
contains CL commands and, optionally, inline data files for one or more jobs. 
An input stream will also be used to execute the program. 


The input stream containing CL commands and the RPG source (Figures 3-1 
through 3-3) for the MLG520 program is keyed onto a diskette using an offline 
device, such as the 5280 Distributed Data System (Figure 3-5). When placed 
on diskette, the input stream becomes a diskette data file, which is identified 
by a specific data file label. In this example, the label is SOURCE. 
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Figure 3-5. Using an Offline Device to Create an Input Stream 
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To get the input stream from diskette into the system, a system user Such as 
the system operator places the diskette in the diskette magazine drive and 
enters the Start Diskette Reader (STRDKTRDR) command. This command 
might be entered, for example, from the system operator menu at the system 
console or another work station. 


SYSTEM OPERATOR MENU 
Select one of the following: 
. DSPJOBQ (jobq? » STRPRITWTR device,outq 
. DSPOUTQ loutdq) . CNLWTR writer 
. SNDMSG tomsgq,(type),msg . STROKTRDR device; label 
» CALL program . CNLRDOR reader 
. Execute command . SIGNOFF (*NOLIST *LIST) 
. SBMJOB (job?},( jobd),(cemd) 
Option: 5 Parms: 
Msg or emd: strdktrdr dev(qdkt) label(source) loc(¥s1) 


Log requests: *YES CF3-Command entry CF4-Prompt (5 only) 
CF6-DSPMSG QSYSOPR CF7-DSPSBS CF8-DSPSYS 





The diskette file to be read is indicated by specifying the label SOURCE. 


When the STRDKTRDR command is executed, a spooling reader reads the 
input stream into system storage. The reader puts an entry on a job 

queue that identifies the commands and source in the input stream as a batch 
job and creates an inline data file to hold the RPG II] source (Figure 3-6). 
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Figure 3-6. Reading an Input Stream from Diskette to Compile MLG520 


The CL commands in the input stream provide the necessary instructions for 
the system to process the batch job that compiles the RPG III program 
MLG520. 











The // JOB statement identifies the beginning of a batch job. This statement 
and all statements that begin with // are recognized by the spooling reader. 
The slashes must be in positions 1 and 2. The command can begin in position 
3 or can be preceded by blanks. The default |BM-supplied job description, 
QBATCH, is used in this approach because a job description (the JOBD 
keyword of the JOB command) is not specified. A job description contains a 
set of job-related attributes (such as priority, job queue, and message logging 
level). One or more of the attributes may be overridden by specifying the 
attributes on the // JOB statement; but, in this case, they are not overridden. 
A job name may be specified on the // JOB statement to help the user 
identify the job in the system. In this case, a job name is not specified and the 
job name defaults to the job description name, QBATCH. The // JOB 
statement in this example does not specify a job queue name; therefore, the 
job queue on which this job is placed is determined by the command used to 
start the spooling reader (the STRDKTRDR command in this example). If a job 
Queue name is not specified in the STRDKTRDR command, the job is placed 
on the default job queue, QBATCH, for execution in the QBATCH subsystem. 


The CRTRPGPGM command instructs the system to compile the RPG III 
program from the source statements in the job’s inline data files SOURCE, and 
to store the executable (compiled) program under the name MLG520 so that it 
can be called later. 


The // DATA statement identifies the data that follows as an inline data file, 
which, in this case, is called SOURCE. The keyword FILETYPE identifies the 
data as source (*SRC) so that the system can correctly process it. The data in 
this file named SOURCE consists of the RPG III source statements (Figures 
3-1 through 3-3), which follow the DATA command. Because the 
CRTIRPGPGM command specified the file SOURCE, the RPG program will be 
compiled from these source statements. 


The // ENDJOB statement is at the end of the input stream and designates 
both the end of the inline data file and the end of the job. 
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When the diskette reader has finished reading the input stream from the 
diskette and has created an entry for the job on the QBATCH job queue, as 
shown in Figure 3-7, a message appears on the system operator message 
queue saying that the job has been successfully spooled into the system. 
When the job is the highest priority job on the job queue, CPF initiates the job 
and the CRTRPGPGM command is executed. The RPG III program is compiled 
and stored in the default system general purpose library, QGPL. At the same 
time, a compiler listing of the RPG III program is generated and placed on the 
default output queue OPRINT. 
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Figure 3-7. Creating an RPG III Program from Diskette 
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Because no other CL commands follow the CRTRPGPGM command (see 
Figure 3-6), CPF terminates the job, generates a job log, and places the job log 
on the QPRINT output queue along with the RPG III compiler listing. The 
compiler listing and the job log are printed when the output priority of the job 
is the highest on the output queue. This printing is done because the Start 
Printer Writer (STRPRTWTR) command was executed when you prepared your 
system for this example (see Preparing for Daily Operations in Chapter 2). 
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Executing the Label Printing Program 


Once the MLG520 label printing program is compiled, system users can print 
mailing labels by calling the program and providing master records for the 
program to process. In this approach, the MLG520 program is called by a CL 
command (the CALL command) in an input stream that is read from diskette. 
The input stream also contains name and address records (master records) that 
the MLG520 program is to print. The format of the name and address records 
is described under Characteristics in Chapter 1. 


An offline device is used to key the input stream onto diskette, as was done 
when the MLG520 program was compiled (see Figure 3-5). The input stream 
containing the CALL command and the name and address records is read from 
diskette and placed on the QBATCH job queue for processing, as shown in 
Figure 3-8. 






























STRDKTROR as 

Command oo ae! 
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// JOB 

CALL MLG520 /*#Label Printing Program*/ 

// DATA FILE( INPUT) 
i Input 
° (name and address records) Stream 


// ENDJOB 





Figure 3-8. Reading an Input Stream from Diskette to Execute MLG520 


Because this input stream is similar to the input stream for compiling the 
MLG520 program (see Figure 3-6), only the differences are discussed below. 


The CALL command instructs the system to execute the previously compiled 
RPG Ill program MLG520. The /* Label Printing Program */ comment 
helps to document the CL command. A CL comment always begins with /* 
and ends with */. 


The // DATA statement identifies the beginning of the inline data file, which 
contains the name and address records. The name INPUT is specified for this 
inline data file. The same file name is declared as the input file in MLG520 
label printing program (see Figures 3-1 and 3-2). 
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When the job is selected from the job queue, MLG520 is called into execution 
(Figure 3-9). The program reads each input record (name and address) from 
the inline data file INPUT and writes each mailing label. The mailing label 
output is spooled and placed on the QPRINT output queue. A job log, which 
lists the input stream commands and any system messages, is also produced. 
The job log is spooled and placed on the QPRINT output queue along with the 
mailing labels. The mailing labels and job log can be printed when the job 
terminates. 
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Figure 3-9. Calling a Job into Execution and Placing Labels on an Output Queue 





An example of mailing labels printed by the MLG520 program is shown on the 
following page. 
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11233 
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NEW YORK 

NY 12345 
RL JONES 
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NEW YORK 

NY 12346 
™™ JOHNSON 
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IA 45678 
RP MILLER 

179 WEST CENTER 
MILWAUKEE 

WS 67890 
ED ROBERTS 

345 N DIVISION 
CHICAGO 

It 65656 
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RECOVERY CONSIDERATIONS 


If the mailing labels were not printed or were printed incorrectly, the cause is 
most likely an error in: 


e The name and address records or associated commands on the diskette 
used to execute the label printing program. 


e The RPG III source statements or associated commands on the diskette 
used to compile the label printing program. 


In either situation the input stream must be correctly keyed on diskette and 
read into storage again. 


Similarly, if a system failure occurred while the label printing program was 
executing, the diskette containing the input stream to execute the program 
must be read into storage again. 











Chapter 4. Batch Input and Batch Maintenance 


OVERVIEW 


The approach described in this chapter expands on the previous approach in 
Chapter 3. In addition to printing mailing labels, this approach provides batch 
maintenance of a master file in the data base. Externally described data files 
with different access paths are used. This approach to the application has the 
following characteristics: 


« Transaction records are read from diskette as part of an input stream and 
placed in an inline data file, INPUT. 


« A CALL command in the input stream calls a maintenance program, 
MLG310. The program reads the transaction records from the inline data 
file and updates a physical data base file. MLGMASP, which contains the 
master records. 


e The mailing list print program, MLG525, prints mailing labels from the 
MLGMASP master file using a different access path and selection criteria 
provided by a logical files MLGMASL. An input stream read from diskette 
creates the logical file, calls the mailing list print program, and then deletes 
the logical file after the program has been executed. 


¢ All files are created as externally described data files. 
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DATA BASE FILES 





As the amount of data that you keep on your system grows and the 
interrelationships between various objects become more complex, an organized 
approach to handling this data is essential. The System/38 data base is an 
organized collection of all data files stored in the system. System/38 allows 
you to store data in one physical structure, but allows multiple users to access 
the data in various logical formats, organizations, and sequences. 
Consequently, data redundancy is reduced and you can now easily meet 
requirements that were difficult or impossible to meet on many previous 
systems. 


A data base file is an organized collection of related records in the data base. 
There are two types of data base files on the System/38: 


« A physical file is a data base file that contains data records. All the records 
have the same format; that is, they are fixed-length records and they 
contain the same fields in the same order. 


« A logical file is a data base file through which data that is stored in one or 
more physical files can be accessed by means of record formats and/or 
access paths that are different from the physical representation of the data 
in the data base. 


A file must be created on System/38 before a program can use the file. An 
RPG Ill program cannot create a file. RPG Ill can add records to a file that 
was created previously by a CL command. When a physical file is created, no 
data records exist in it. A program, such as an RPG III program, or the Copy S) 
File (CPYF) command must be used to add records to the file. In this 

application approach, an RPG II! maintenance program, MLG310, is used to add 

records to the file. 





Access Paths 


Data in both types of data base files can be processed by a program. The file 
definition includes an access path, which is the means by which CPF provides a 
logical sequence to the data records in a data base file so that they can be 
processed by a program. There are two types of access paths (keyed 
sequence and arrival sequence), but only the keyed sequence type is discussed 
in this publication. A keyed sequence access path is based on the content of 
key fields within a record. Using key fields, records can be logically sequenced 
in a file by specifying: 


¢ The fields in the record which are key fields 
« Ascending or descending order for the key field(s) 
« The order of the key fields when multiple fields compose the key 


Selection criteria can also be used to form a subset of records or to limit the 
number of records in a logical file. 





For more information on keyed sequence access paths, refer to the CPF 
Programmer's Guide. Specifying an access path on data description 
specifications will be discussed later. 


In this approach, a physical master file) MLGMASP, is created from data read 
from the diskette. 


The following illustration shows physical data records in storage. The access 
path orders these records by the key field which, in this case, is account 
number (ACTNUM). When the program requests a specific key, the access 
path is used to access the specific records and to present the records to the 
program. 


ACTNUM ACTTYP NAME ADDR CITY STATE ZIP 


10522 a JJ JOHNSON | 489 WHITNEY ST CHICAGO] IL 54857] Record 1 
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Note that the order of the physical data records is not important. The access 
path contains both the key to match against the program's request and a 
corresponding entry (record number) to determine where the physical data 
record is located. 
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Multiple access paths should be created when physical data needs to be 
accessed in different sequences. For example, the records in the following 
illustration must be accessed by both a maintenance program and a label 
printing program. 


ACTNUM ACTTYP NAME ADDR CITY STATE ZIP 


















f29498/914 = | AMCASE | 23 MAIN ST DALLAS |TX ff 3 Record 4 
47376 | JLJONES | 12230AK AVE | DETROIT 1 30398 
7 DETROIT] MI Y903991 Record 3 
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The maintenance program uses the account number (ACTNUM) access path. 
The label printing program uses the zip code (ZIP) access path. 


A file must be created for each access path that is required. In this example, 
the account number access path is defined in the physical file MLGMASP 
(where the data is actually stored) and the zip code access path is defined in 
the logical file MLGMASL. If additional access paths were needed for the data 
in MLGMASP, one additional logical file would have to be created for each 
additional access path needed. Although only one key field is used for each 
access path in this example, more than one key field can be Specified in each 
file that defines a separate access path. 











Externally Described Data Files 


The physical data base file and the logical data base file used in this approach 
are externally described. The records of an externally described data file are 
described to CPF through the use of data description specifications (DDS) 
when the file is created. The DDS defines the individual fields of the file and 
their characteristics. 


A file can be defined without specifying individual fields, because the field 
descriptions can be automatically included in the program when it is compiled. 
However, external field descriptions are used in this application because of the 
following considerations: 


e Any fields used as keys or in selection criteria must be defined. 
« Field definitions are not coded in every program because the RPG III 
compiler can automatically copy the definition. This helps to keep field 


names and their attributes consistent. 


e Two of the interactive data base utilities (data file utility and query utility) 
require that fields be externally defined. 
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MASTER FILE 


In this example, a definition for the file will be created in a batch job. Batch 
jobs will also be used to create and execute the programs used in this 
approach. 


The physical file definition for MLGMASP is created by an input stream. This 
input stream is a file on diskette with a label of SOURCE1, as shown in Figure 
4-1. The input stream is read into storage when you issue a STRDKTRDR 
command with SOURCE1 specified as the label. 


| Storage | 





Job Queue < 
STRDKTRDR[ GE ne Se i 
Command Prat toe | - 
al ies Reacsas = —— QINLINE | 
— €oBATCH | > DDS 


Source 








// JOB 

CRTPF FILE(MLGMASP) SRCFILE(QINLINE) 

// GATA FILETYPE(*SRC) Input Stream 
° With Label 
e {OOS source) SOURCE1 


// €NOJOB 





Figure 4-1. Reading an Input Stream from Diskette to Create MLGMASP 


The CRIPF command in the input stream creates a physical file. The file is to 
be named MLGMASP (physical master file). 


The // DATA statement preceding the DDS source statements defines the 
DDS source as an inline data file. Because the // DATA statement does not 
specify a file name, the inline data file containing the DDS source is assigned 
the default name of QINLINE when the input stream is read from diskette into 
storage. 


The DDS source in the inline data file is shown in Figure 4-2. 
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DDS for MLGMASP File 


The first line of the DDS is a comment (* in position 7 designates a comment) 
that identifies the source to the programmer. The * in position 8 is used as a 
convention to format the first comment line in a standard manner. 


The UNIQUE entry specifies that the access path is to contain unique keys. A 
keyed sequence access path is specified using the ACTNUM field. 
Consequently, each account number must be unique; if you attempt to add a 
new record with an account number that already exists in the file, that record 
will be rejected. 


The R in position 17 defines a record format named MLGMASR. A record 
format defines the names and order of the fields in the records contained in a 
file. This definition includes the record name and field descriptions for the 
fields contained in the record. RPG III requires that the names of files and the 
names of formats defined by externally described data be unique within the 
program (a format may not have the same name as the file). Each field is 
defined with a name and a length. Decimal positions are defined for those 
fields that are to contain only numeric data. 


In the last source line, the ACTNUM field is specified as the key field for this 
file by placing a K in position 17. 
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USING TRANSACTION RECORDS 


In this approach, the data base master file, MLGMASP, is updated from 
transaction records that are keyed on diskette and then read into the system. 
A transaction record is defined as follows: 


Decimal Position 
Field Name | Field Description Length Positions Range Field Type 


BATNUM Batch number Numeric 
TRNTYP Type of transaction Character 
ACTNUM Account number Numeric 


ACTTYP Type of account Numeric 
NAME Name Character 
ADDR Address Character 
CITY City Character 
STATE State Character 
ZIP Zip code Numeric 




















The record definition is the same as that discussed under Mailing List 
Application in Chapter 1 except for the addition of fields to contain the batch 
number and type of transaction. The batch number is assigned externally and 
allows a unique control number over a group of transactions. 


The type of transaction is designated by: 


A for addition 
C for change 
D for deletion 


If a transaction is coded for addition, all fields must be entered. If a 
transaction record is coded for change, all fields of that record must be 
reentered in the transaction record, even if some of the data is the same as 
data in the master record. To change the account number of a master record, 
the existing master record must be deleted and a transaction record must be 
entered with the new account number. 


If a record is coded for deletion, only the batch number, type of transaction, 
and account number are entered. 











MAINTENANCE PROGRAM 


The maintenance program, MLG310, reads an inline data file of transaction 
records and updates the existing master data base file as shown below. 


Maintenance 
Ea Program 


(transactions) MLG310 


Data Base File 


MLGMASP 





The program is written in RPG III. It is coded to read a transaction file 
(INPUT), update the mailing list file (MLGMASP)}, and produce a spooled 
Output file (QPRINT), to be printed later. The INPUT transaction file is created 
as an inline data file when the transaction records are read into the system 
from diskette. The transaction records are described within the program by 
RPG input specifications. 


The source for the maintenance program is shown in Figures 4-3 through 4-8 
(see the following pages). No H Specification statement is required. 
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Control and File Description Specifications, shown in Figure 4-3, identify the 
three files to be used. The MLGMASFP file is coded as follows: 


e MLGMASFP in positions 7 through 14 designates a file name that must be 
defined to the system. 


« U in position 15 designates an update; the records are changed during the 
program. 


« F in position 16 designates full procedural; the programmer, rather than the 
RPG Ill program cycle, specifies when the file is to be read. 


« E in position 19 designates an externally described file; the RPG Ill compiler 
copies the field descriptions from the externally described file at compilation 
time. 


« K in position 31 designates a keyed sequence file. 
e DISK in positions 40 through 46 designates device type. 


« A in position 66 designates additions; the program can add new records to 
the file. 


When an externally described file is used, the record length entry (positions 24 
through 27) must be blank. When a program-described file is used, the record 
length must be entered. RPG ||| on System/38 does not use the block length 
entry (positions 20 through 23). The INPUT and QPRINT files are similar to the 
files with these names in the previous approach. 
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Figure 4-3. Control and File Description Specifications for MLG310 Maintenance Program 
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Extension and Line Counter Specifications, shown in Figure 4-4, describe two 
compile-time arrays that are used to validate the account type and state being 
entered. The data for these arrays is shown later in Figure 4-8. 
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Figure 4-4. Extension and Line Counter Specifications for MLG310 Maintenance Program 





Input Specifications, shown in Figure 4-5, define the field names for the 
transaction record because the file is program-described. These names are 
different from those defined in the master record because RPG has a single 
storage area for each defined field name. If the same field names are used in 
both files, the master record data would overlay the transaction record data 
when the master record is read. No input specifications are needed for the 
externally described file. 





IEM | RPG INPUT SPECIFICATIONS GXx21-9084 UM/050" 


fernauonel Gunes Machines Corporatio ft Printed in U.S.A. 


roam cme Lemme |] [|__| cre tre name Ara 
[Programmer foe smateetion ‘J ey = TT TT | | 
> External Field Name 
Field Location 
5 Record Identification Codes 


Data Structure 


Occurs 












Program 
‘denuticarion WAL [G13 10 | 
n Tones 


Field 
Indicators 
; Pius [Minus] or 
44 45 46 47/49 49 Su 51/57/53 54 55 56 57 58/69 60/61 62/63 64/45 G6/67 68/69 7O|71 72 72 74 


++ Hat TH elabelaletaba SEE 
{| lat | | telpalgizinal | TT TEE TT ET 
He aaa EEE 








Filename 
or 
Record Name 










RPG 
Fieid Name 









Decimal Positions 
Control Level (L1-L9) 
Matching Fields or 
Chaining Fields 

Field Record Relation 


Length 





g 
aig 
42743 


eT stag 
StH 
lel | Widi@ixialelrinmg | tT tT I 
is] | Weisiglxialelzinil | | | | | 
4 | iste] [xwlalfel | | | | | I | wee 


a 
a 
Hl | 
i ad 
9 Ixlalololal | | | | + 

RE 

i 


| | bet | i 

Sie | ler icliriy! || ttt 
8 l69| Ixis|ralriel | | | tI 

7 | iia WxizielPl | tt | | | 


PP character 


= Ee Ee eee 


=e 
ser 


Figure 4-5. Input Specifications for MLG310 Maintenance Program 
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Calculation Specifications, shown in Figure 4-6, specify the operations to be 
performed on the data. The program sets off certain indicators to allow proper 
output for each transaction. The account number in the transaction record 
(XACTNM) is used to retrieve a master record of the same number. The name 
of the record (MLGMASR) is used instead of the name of the file because 
MLGMASFP is an externally described file. If no master exists, indicator 61 is 
on. If the master is found, it is printed by the EXCPT operation, which 
specifies a label (MASTER) that is used on the output specifications (shown 
later in Figure 4-7). 


The program tests the transaction type and branches to the required 
processing routine. The compare and branch instructions (CABxx) are used to: 


e Make a comparison 


« Set on an indicator if the compared items are equal 


¢ Branch to a tag if the compare function is satisfied 
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To add records, the transaction type code is A. The account number of the 
new record is compared with existing account numbers in the master file as 
( shown in the following illustration. 


Flowchart for Adding Records (Transaction Type A) 
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If the new record’s account number exists in the master file, indicator 61 is set 
on, an error message Is printed, and the transaction is ignored. 


The system will reject a request to add a nonunique key because the file is 
defined to contain unique keys (ACTNUM in this case). If there is a duplicate 
account number, the program terminates. 


In this example, the program attempts to retrieve the record for the specified 
account number before adding the specified account number. In this way, the 
duplicate key error is avoided. 


If the account number for the new record is unique, the EXSR CHECK 
statement invokes a subroutine to check the validity of the XACTTP and 
XSTATE fields by using LOKUP operations against arrays. Indicator 80 Is set 
on, an error message is printed, and the transaction is ignored when one or 
both of these fields contains data that is not valid. If the data is valid, all of 
the transaction data fields are moved into the new master record fields (all 
fields in the master record must contain data) by the EXSR MOVNEW 
subroutine. The new master record is then written into the master file by the 
WRITE statement. No output specifications are required because the WRITE 
operation code supplies as output all fields for the externally described record. 


To change records, the transaction type code is C. The account numbers in the 
master file are searched for the account number of the record to be changed 
as shown in the following illustration. If it is not found, indicator 61 is set on, 
an error message is printed, and the transaction is ignored. 


If the master record is found, the EXSR CHECK statement invokes a subroutine 
to check the validity of the XACTTP and XSTATE fields by using LOKUP 
Operations against arrays. Indicator 80 is set on, an error message is printed, 
and the transaction is ignored when one or both of these fields contains data 
that is not valid. If the data is valid, the transaction data is moved into the 
master record field by the EXSR MOVNEW subroutine. The updated master 
record is then written into the master file by the UPDAT statement. The 
UPDAT operation code assembles all of the fields for the externally described 
record and replaces the existing fields. 











Flowchart for Changing Records (Transaction Type C) 
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To delete records, the transaction type code is D. The account numbers in the 
master file are searched for the account number of the record to be deleted as 
shown in the following illustration. 





Flowchart for Deleting Records (Transaction Type D) 
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If the account number is not found, indicator 61 is set on, an error message Is 
printed, and the transaction is ignored. 


If the master record is found, it is deleted by the DELET statement. No 
program can retrieve this record after it is deleted. 


If the specified transaction type is not One of the three valid codes, indicator 
71 is set on and an error message is printed. 
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The output specifications, shown in Figure 4-7, print heading lines and format 
the output. If indicator 01 is on, the transaction record is printed. An error 
message, which lists any rejected transactions, is printed if an error indicator is 
on. 
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MASTER is the EXCPT name that is specified by the EXCPT operation code 
(see the previous discussion of the calculation specifications). The compile 
time arrays (Figure 4-8) are part of the program. 
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Figure 4-8. Compile-Time Arrays for MLG310 Maintenance Program 


The master record is printed as it existed before changes were made to it, and 
then the transaction record is printed. The printer layout for the maintenance 
program is shown in Figure 4-9. 
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Figure 4-9. Printer Layout for MLG310 Maintenance Program 
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Creating the Maintenance Program 





The maintenance program is created by an input stream that is similar to the 
input stream previously used to create the label printing program, MLG520 (see 
Figure 3-6 in Chapter 3). In this case, MLG310 is specified as the program: 


// JOB 
CRTRPGPGM PGM(MLG310) SRCFILE(SRC310) 
// DATA FILE(SRC310) FILETYPE(*SRC) 


e (RPG III source) 
// ENDJOB 


This input stream is a file on diskette with a label name of SOURCE3. To 
create MLG310, issue the STRDKTRDR command with SOURCES specified as 
the label. 


The RPG III source for MLG310 is shown in Figures 4-3 through 4-8. 


Executing the Maintenance Program 


The maintenance program is executed by an input stream that is similar to the 
input stream previously used to execute the label printing program, MLG520 
(see Figure 3-8 in Chapter 3). In this case, MLG310 is the program called and 
the data is transaction records (the transaction records are described earlier in 
this chapter under Using Transaction Records): 





// JOB 
CALL MLG310 /* Mailing List Maintenance Program */ 
// DATA FILE(INPUT) 


e« (transaction records) 


// ENDJOB 


The input stream is a file on diskette with a label name of MLGMAINT. To 
execute MLG310, issue the STRDKTRDR command with MLGMAINT specified 
as the label. 


When the program executes, the master file is updated. New records are 
written at the end of the file, but the access path on account number is 
modified immediately so that the records can be accessed in the correct order 
(they are not moved within the file). Records that have been changed are 
updated in place. They are not moved within the file. Records that have been 
deleted can never be accessed again. A deleted record occupies space on the 
system; however, this space can be reclaimed by reorganizing the file. For 
information on how to do this, refer to the CPF Programmer's Guide. 
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MAILING LIST PROGRAM 


The mailing list program, MLG525, prints the labels for a specified mailing list. 
The program is written in RPG III and uses the RPG program cycle to read and 
print mailing list records. 


The source for this program is shown in Figures 4-10 through 4-12. The input 
file for this program is MLGMASP. This approach assumes that the sequence 
and selection criteria for each mailing list will vary. When the program is 
executed, the Override with Data Base File (OVRDBF) command is specified so 
that the program uses a logical file to access the data in MLGMASP. The 
override command specifies the name used in the program and the file to be 
used on the system. The same program its used regardless of the mailing list 
sequence. The override is needed because the program is compiled to execute 
against the physical data, but the data needs to be in a different logical 
sequence. Overrides can also be used to redirect data and temporarily modify 
the attributes of the file. 
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Figure 4-10. Control and File Description Specifications for MLG525 Print Program 
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Figure 4-12. Output Specifications for MLG525 Print Program 
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The record format (MLGMASR) in the physical file (MLGMASP) is the same as 
that in the logical file (MLGMASL). Consequently, the System/38 level 
checking function is passed successfully. Level checking ensures that the 
format that was copied into the program at compilation time is the same 
format that the program uses at execution time. If the formats are not the 
same, the System/38 terminates the program when it attempts to open the 
file. 


The E in position 19 of the file description specification, shown in Figure 4-10, 
indicates that an externally described file, MLGMASP, is used. The RPG III 
compiler copies the field descriptions from MLGMASP at compilation time, so 
the fields do not have to be described in the RPG program. However, the input 
specification, shown in Figure 4-11, is used to add information to the record 
format description that was copied at compilation time. This input specification 
assigns the record identifying indicator 01 to the record format, MLGMASR 
(the record format name, MLGMASR, is used on the input specification instead 
of the file name). At execution time, the system retrieves a record from the file 
and provides the format name of the record it read to RPG Ill. If the format 
name is MLGMASR, RPG III sets on the record identifying indicator 01. This 
indicator is then used to condition the output operations. 


Creating the Mailing List Program 


The mailing list print program is created by an input stream that is similar to 
the input stream previously used to create the label printing program, MLG520 
(see Figure 3-6 in Chapter 3). In this case, MLG525 is specified as the 
program. The input stream is a file on diskette with a label name of 
SOURCE4. To create MLG525, issue the STRDKTRDR command with 
SOURCE4 specified as the label. 


The RPG III source statements shown in Figures 4-10 through 4-12 follow the 
// DATA statement in the input stream. 
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Executing the Mailing List Program through a Logical File 


lf you have requests for several different mailing lists, you can create a logical 
file to access the data for each mailing list and then delete the logical file after 
it is used. An override (OVRDBF command) can be used to temporarily 
substitute this logical file for the file specified in the program. 


The logical file used in this approach is named MLGMASL and is designed to 
do the following: 


¢ Select only records from the states MN, ND, and SD 

¢« Select only private accounts (ACTTYP=5) 

« Sequence the access path by zip code 

Figure 4-13 shows the DDS for this file. The record format (MLGMASR) used 
in the physical file is also used in this file. The physical file is identified by the 
PFILE keyword. Because the same record format name is used and no fields 


are defined, all fields defined in the physical file are automatically defined for 
this logical file. 
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Figure 4-13. DDS for MLGMASL File 
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The key field (K in position 17) specifies that the file is to be sequenced by zip 
code. 


The select logic (S in position 17) specifies the values for the STATE field 
(which can be MN, ND, or SD) and that the ACTTYP field must equal 5. Only 
records meeting both of these selection criteria will be on the access path; 
consequently, Only those records will be read by the program. 


The following input stream creates the logical file definition for MLGMASL and 
then executes the mailing list print program through the logical file: 


// JOB 
CRTLF FILE(MLGMASL) SRCFILE(QINLINE) 
// DATA FILETYPE(*SRC) 
e (DDS source) 
OVRDBF FILE(MLGMASP) TOFILE(MLGMASL) 
CALL MLG525 /* PRINT MAILING LABELS */ 
DLTF MLGMASL 
// ENDJOB 


This input stream is a file on diskette with a label name of SOURCE2. To 
create MLGMASL and execute MLG525, issue the STRDKTRDR command with 
SOURCE2 specified as the label. The input stream is similar to those 
previously shown (see, for example, Figure 3-8 in Chapter 3 and Figure 4-1). 
The CRTLF command creates a logical file named MLGMASL as described by 
the DDS source, which is shown in Figure 4-13. The create command builds 
an access path over the physical data according to the selection and 
sequencing criteria. It does not duplicate the data. 


The OVRDBF command specifies that the file name MLGMASP is overridden 
to use the file MLGMASL. The program uses the OVRDBF command to 
access the logical file and print the labels for each record on the access path. 
The DLTF command deletes the MLGMASL logical file, including its access 
path, after the MLG525 prcjram has printed master records from MLGMASP 
as defined in MLGMASL. 
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RECOVERY CONSIDERATIONS 


Recovery from error situations likely to be encountered in applications was 
introduced in the section, General Recovery Considerations, in Chapter 2. The 
following specific recovery considerations apply to the application approach in 
this chapter. 





If incorrect data has been entered for a transaction, the entire transaction 
should be reentered with correct data by using the maintenance program 
MLG310. 


lf there is a system failure while the maintenance program is executing, the 
current batch of transactions should be reprocessed in most situations. The 
maintenance program rejects invalid transactions, such as a request to add a 
record with an account number that already exists in the master file. If a 
system failure occurs when you are not executing the maintenance program, no 
recovery iS normally needed. 


To allow you to recover damaged objects (assuming you are maintaining the 
master file with one or more batches per day), the master file could be saved 
every 2 to 3 days and the transactions should be saved from the last backup. 
If the damaged master file is not usable, the backup can be restored and the 
saved transactions can be reprocessed. You should keep both the current 
backup and at least one earlier level of backup. Because you recover by 
reprocessing the transaction, a specific entry for the FRCRATIO parameter is 
not needed for the data base files used in this approach. 
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Chapter 5. Programmer Use of a Work Station 


OVERVIEW 
In Chapter 4, input streams including the transaction records were read from 
diskette to execute batch jobs. Normally, you can be more productive if you 
perform these functions directly from a work station. The remainder of this 
publication assumes that you are working from a display station with a 24-line 
screen (such as a 5251 Model 11 or 12). 
Many of the functions available on the work station are used in the remaining 
application approaches. This chapter introduces the following work station 
functions and shows how they are used for application development: 
e Programmer menu 
e Command prompting 
« Source entry utility (SEU) 
You can use the System/38 work station to transmit information to or receive 
information from the computer as you perform your job. For example, you can 
use the work station to do the following: 
- Enter or change source 
« Request compilations 
« Review the compilation results 
« Enter input streams 


e Enter single batch jobs 


« Request various types of system status (such as a displayed list of active 
jobs) 


« Execute programs 


« Perform debug functions 
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PROGRAMMER MENU 


If you sign on the system with the password for the QPGMR user profile, you 
receive the programmer menu (shown below) as your basic working display. 


PROGRAMMER MENU 

Select one of the following: 

1, Design/execute DFU app (app); »Coptions) 
Design/execute query app (app), »(options) 
Create object object name, type, pgm for CMD, (text) 
Call program program name 
Execute command command 
Submit job (job name), (command) 
Display submitted jobs 
Edit source (srombr), (type), (text) 
Design display format (srembr ) 
Sign off (#NOLIST *LIST) 


evuvawzw rw fwh 
e . 648 = a . tT a - 


20 


Types: BSCF, CBL, CL, CLP, CMD, CMNF, DSPF, LF, PF, PRTF, RPG» TXT 


Option: _ Parm: Type: Parm 2: 
Command: 


Text: Log requests: ¥YES 
Src file: “Sre lib: *LIBL Obj lib: Jobd: QBATCH 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPNMSG 





The programmer menu can be a shortcut to requesting functions that are used 
frequently in performing programmer tasks. By generating the commands 
needed to perform these programmer tasks, the programmer menu helps to 
eliminate repetitive keying and some errors. For the programmer menu to be 
effective, your system needs to have the IDU program product or an equivalent 
installed. Also, a 5251 Display Station Model 11 or 12, or equivalent with a 
24-line screen, must be used because the programmer menu requires a 
24-line screen. 


When you request an option other than option 5, you do not need to key in 
the command; you simply select the desired option and key in only the 
essential information. 











Option 5 allows you to enter a command name and parameters to request a 
function that is not listed as an option on the menu. The following example 
shows how the Create Library (CRTLIB) command can be executed: 


PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app), »(options) 
2. Design/execute query app (app), »loptions) 
3. Create object object name, type, pgm for CMD, (text) 
&. Cal¥ program program name 
Execute command command 
Submit job (job name), (command) 
Display submitted jobs 
Edit source (srembr), (type), (text) 
Design display format (srembr ) 
Sign off (*NOLIST *LIST) 


Types: BSCF, CBL, CL, CLP, CMO, CMNF, DSPF, LF» PF» PRTF, RPG, TXT 


Option: 5 Parm: Type: Para 2: 
Command: j } tbdey) ‘Mailing Li 


Text: Log requests: YES 
Sre file: Sre lib: *LIBL Obj lib: Jobd: QBATCH 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPHSG 





For detailed information on how to use the programmer menu, refer to the 
Programmer's /User's Work Station Guide. 


To take full advantage of the programmer menu, you may need to establish the 
proper environment for application development and maintenance. For 
example, you may need to create specific types of files for an application, and 
you may want to group those files in a special library for convenient access. 
The procedures and considerations for creating and using libraries and files are 
discussed in Chapter 6. 
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COMMAND PROMPTING 


Each command on System/38 has a prompt display that helps you enter the 
command. You can request command prompting for options 3 and 5 on the 
programmer menu by using the CF4 key as follows: 


« Select option 3 and specify an object name and type; then press CF4. You 
receive a prompt display for the appropriate command to create the object 
you specified. The prompt lists all required and optional parameters of the 
command and shows the object name and type you provided. If you key in 
other parameter values on the programmer menu before pressing CF4, those 
values are also shown on the prompt. 


e Select option 5 and specify at least a command name; then press CF4. You 
receive a prompt display that lists the required and optional parameters for 
the specified command. If you key in parameter values on the programmer 
menu before pressing CF4, those values are also shown on the prompt. 


« Select option 5 and press CF4 immediately without specifying a command 
name. You receive a set of menus that help you select the appropriate 
command to perform a desired function. When you select a specific 
command on the menus, you receive the prompt display for that command. 


For example, to request prompting for the CRTLIB command, first select option 
5 and specify CRTLIB: 


PROGRAMMER MENU 
Select one of the following: 
Design/execute DFU app (app), » (options) 
. Design/execute query app (app), ,(optrons) 
. Create object object name, type, pgm for CMD, (text) 
Call program program name 
. Execute command command 
. Submit job (job name), (command) 
. Display submitted jobs 
Edit source (srembr), (type), (text) 
. Design display format (srembr ) 
. Sign off (HNOLIST #LIST) 


eve~uewi uh = 


<<) 


Types: BSCF, CBL, CL, CLP, CMD, CMNF, DSPF, LF, PF, PRTF, RPG» TXT 


Option: 5 Parwi _ Type: Parm 2: 
Command: ¢ 1 


Text: Log requests: *YES 


Src file: Sre lib: #LIBL Obj lib: Jobd: QBATCH 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPMSG 














Then press CF4. The following display appears: 


Create Library (CRTLIB) Prompt 

Enter the following: 
Library name: LIB A) R 
p 


Library type (#PROD *TEST): TYPE #PROO 


Public authority PUBAUT 
(*NORMAL #ALL #NONE): *NORMAL B 
Text ‘description’: TEXT *BLANK 





A) Parameters that you are required to use are designated by R; you must key in a 
valid value. If R is not shown, the parameter is optional. P is shown if the 
optional parameter can be coded positionally (without a keyword). 


B When there is a default for a parameter, the default value is automatically 
displayed; however, you can replace the default value with another valid value. To 
request a listing of valid values, enter a ? instead of a value. 


Command prompting helps you enter correct information and minimize 
keystrokes. For detailed information on using prompting functions, refer to the 
Programmer's /User’s Work Station Guide. 
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SOURCE ENTRY UTILITY 
In addition to entering source from diskette, you Can enter and edit source and 
Create source members from a work Station using the source entry utility 
(SEU), which is part of the Interactive Data Base Utilities (IDU). SEU operates 


on members of a source file. 


A member is an identifiable group of records in a data base file. Each member 
conforms to the characteristics of the file and has its own access path. 


When you use SEU, source records are entered into a member of a data base 
file. IBM supplies several source files, each for a different type of source. The 
four source files used in this example are: 

¢ QOQRPGSRC for RPG III source 

« QDDSSRC for DDS source 


e QCLSRC for CL source 


e QUDSSRC for IDU source 











A source file can have multiple members, with each member containing a 
separate set of source statements, as shown in the following illustration. 


In this illustration, each member of file QRPGSRC contains the source 
statements for a different RPG program. Similarly, each member of the file 
QCLSRC contains the source statements for a different CL program, and each 
member of the file QDDSSRC contains the source statements for a different 
file. 


The name of the member is the same as the name of the associated program 


or file, unless you specify a different name when you create the program or file 
from the source. 


Source File 
QORPGSRC 


Members 


Source for Source for Source for Source for 
RPG Program | RPG Program | RPG Program RPG Program 
MLG310 MLG311 MLG520 MLGxxx 


Source File 
QDDSSRC 


Members 


Source for Source for Source for Source for 
Physical File Logical File Display File Physical File 
MLGMSTP MLGMSTL MLGO35CD MLGxxxP 


Source File 
QCLSRC 


Members 


Source for Source for Source for Source for 


CL Program CL Program CL Program CL Program 
MLGO0O5C MLGO35C MLG315C MLGxxxC 
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There are several advantages in using SEU to create or update members of a 
source file: 


e Source entered through SEU is online and can be easily controlled by using 
Online data storage and maintenance. For example, a source file is saved 
the same way as other types of files and the date-of-last-change is 
automatically kept as part of each record. 


e When a source statement is entered, its syntax can be automatically 
checked for validity. Coding and keying errors (such as ZADD entered for 
Z-ADD) are found; however, relational errors (such as a GOTO without a 
TAG) are not detected. 


« While a source statement is being entered, the formats supplied by IBM for 
source types, such as DDS and RPG, can be used to enter data only in 
fields that apply to a format. This method of entering data can prevent both 
positional and field-content keying errors. 


« The following functions are available to help you create and update source: 


Adding or deleting source statements 

Changing existing source statements 

Moving or copying source statements within a member 

Copying source statements from one source file member to another 
Searching (scanning) for a specific character string 

Selecting a particular source member from a list of members in a file 


SEU can be invoked by using the programmer menu as follows: 


« Select option 8 to create a new source member or change an existing 
source member. 


« Specify the name of the source member (srcmbr) to be created or changed. 


« Specify the type, such as RPG or CLP. 











Assume that you want to add (create) a new source member for an RPG 
program PROGS. To request SEU, you select option 8 and enter the member 
name and type on the programmer menu: 


PROGRAMMER MENU 
Select one of the following: 
Design/execute DFU app (app), sCoptions) 
Design/execute query app (app), »loptions) 
Create object object name, type, pgm for CMDs (text) 
Call program program name 
. Execute command command 
. Submit job (job name), (command) 
. Display submitted jobs 
. Edit source (srcmbr), (type), (text) 
. Design display format (srembr ) 
Sign of f (*NOLIST *LIST) 


Types: BSCF, CBL, Cl» CLP, CMD, CMNF, DSPF, LF» PFs PRIF> RPG, TXT 


Option: 8 Parm: PROGS Type: RPG Parm 2: 


Command: a ee 


a 

Text: Log requests: *YES 

Sre file: Sre lib: *LIBL Obj Lib: Jobd: QBATCH 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPHSG 





Through SEU, a member PROGS is added to the appropriate source file for the 
type of source you specified. Because you specified RPG for the source type 
in this example, the member is added to the QRPGSRC file. However, if you 
had specified a different source file (in the Src file field), the member would 


have been added to that file instead of QRPGSRC, even though you specified 
RPG for the type. 
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You next receive an SEU edit display an which you can enter the source 
statements for the new member: 


SEU US W:l Mbr: PROGS Scan: 
FMT Ho sw ces Wietearea cers Li GGOV 1 3 44a ease Caeaw scahesavk-e FL aitacecer Ga ata Wit ele ale eee a eteeraneraans 
eS - ##88BEGINNING OF DATA###HH 
$69606063080END OF DAT A203 360608 


— 


Enter I (insert), IFff (insert under format ff), IPff (insert with 
© prompt ff) or A (copy after) at cursor. RPG ff values are: 
Mt, HHS F FCs FXsEx Le Le Je IXsJX108»95,C,0sP5U 


For wore help press HELP. 


© Hember PROGS added to file GRPGSRC.QRPG 


Q The cursor is initially positioned here for entering a line command. 
© Instructions for using line commands. 


© Message indicates that new member was added. 


You specify how you want to enter the source statements by entering one of 
the SEU line commands in the position indicated by the cursor. For example, 
you might enter the line command !PH to indicate that you want to insert a line 
(1) with prompting (P) for the RPG III control (H) specifications, and input fields 
wauld be shown at the bottom of the screen to prompt you for entries in the 
format of the control specifications. As indicated on the display, you can 
obtain additional details about the line commands by pressing the Help key. 











As you enter each source statement, it is given a Sequence number: 


SEU US W:1 Mbr: PROGS5 
POE: cases Mack, was ete: 2 See 4 
HXHXBEGINNING OF DATA 3% 
0001.00 F % SAMPLE PROGRAM 5 
0002.00 F % 
0003.00 FCUSMING CF E 
0004.00 FCUSMSTL IF E K 
0005.00 START TAG 
0006.00 EXFMTCUSPMT CUST# PROMPT 
0007.00 15 SETON 15 = END PRO 
0008.00 15 GOTO END 
0009.00 CHAINCUSREC GET ADDR REC 
99 GOTO START 99 = NOT FOU 
EXFMTCUSFLDS WRITE ADDR R 
GOTO START 
END TAG 
SEEHMXEND OF DAT A2¢3636963603 


0010.00 
0011.00 
0012.00 
0013.00 


aAaAagANAANAAaANn 





If you need to use an SEU line command again, you key it in over the 
sequence number. 


Programmer Use of a Work Station 5-11 


When you have completed entering the source statements, you press the CF1 
key. An exit display appears next: 





SEU EXIT 


Select one of the following: 
. Exit without update 
Exit and update member 
Exit and create a new member 
Update member, no exit 
Create member; no exit 
Return to edit screen 


Option: 2 
MEMBER FILE LIBRARY 


For option 2 to 5: PROGS QRPGSRC__—«ss«s«@RPG 
Resequence member (Y N): Y Start: 1,00 Increment: 1,90 


For options 1 to 3: 
Return to member list (CY N): 


For options 1 to 6: 
Print source listing (Y N): N 


TOTAL RECORDS ADDED CHANGED DELETED SYNTAX ERRORS LEFT 





Up to this point, the source statements you have entered have been placed in 
an SEU work space. What you specify on the exit display determines whether 
the source Is actually placed in the member. Because you want the source 
statements to be placed in the member PROGS in this example, you select 
option 2 to update the member. If you select option 1, the source file will 
remain as it waS when you entered SEU. 





To change an existing source member, you follow a similar procedure. For 
example, to change the source for the RPG program MLG310, you select 
option 8 and specify the name and type on the programmer menu: 


PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app), »Coptions) 
2. Design/execute query app (app), »loptions) 
3. Create object object name, type, pgm for CMD, (text) 
4. Call program program name 
5. Execute command command 
6. Submit job (job name), (command) 
7. Display submitted jobs 
6. Edit source (srembr), (type), (text) 
9. Design display format (srombr ) 
90. Sign of f (*NOLIST *LIST) 


Types: BSCF ; CBL, CL, CLP, CMD, CMNF, DSPF, LF, PF, PRTF, RPG, TXT 


Option: § Parm: MLG310 | Type: RPG) Parm 2: 
Command: _ 


Text: Log requests: *YES 


Sre file: Sre lib: *LIBL Obj lib: Jobd: QBATCH 
CF3-Command entry CF46-Prompt (3 & 5 only) §CF6-DSPMSG 
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If you selected option 8 and specified a source type without specifying a 
member name, you would first receive a list of all members in the source file: 


SEU MEMBER LIST 
File: QRPGSRC Library: QRPG 
Enter member name or select member from list below: 


MLG6520 
MLG6525 


oe me] wists. 


1 - Select member to edit, i 9 - Remove membar from data base 


ee 772s 
. ar ri = 
(= a ae ee Ee ee 





A Enter the member name here 
or 


® Enter a 1 beside the member name. 


@ = You can remove a member by entering a 9 beside the member name. 


You can select the member you want directly from this display. In this 
example, you want the member MLG310, so you enter a 1 in the input field 


beside MLG310. 











Whether you specify a member name on the programmer menu or select a 
member from the member list, you receive an SEU edit display that shows the 
source statements for the member: 


SEU US W:! 
FMT # 


Mbr: MLG310 Scan: 
be ete ce Ae ok: Somes: Sok ence) VL ah tee hice) aoe ba wile aeons Dele De ee Gactacdiels 
HHHHBEGINNING OF DATA 


0001.00 
0002.00 
0003.00 
0004.00 


H 

Fe 

F* MLG310 MAINTAIN MAILING LIST MASTER WITH TRANSACTIONS 
Fx 


0605.60 
6006.00 
0007.00 


FINPUT IP F 126 SEG 
FMLGMASP UF E K DISK A 
FQPRINT O- F 132 OF PRINTER 
ARCORD 6 6 10 
ARSTAT 25 58 2 


:0009.00 E 


ACCT TYPE CODE 
STATE CODES 

Or6.60 
0011.00 
0012.00 
0013.00 
0014.00 
0015.00 
0016.00 
0017.00 
0018.00 
6019.00 
0020.00 


IINPUT AA O01 
6 CBATNUM 
7 TRNTYP 
120XACTNHM 
130XACTTP 
31 XNAME 
49 XADDR 
67 XCITY 
69 XSTATE 
74 XZIP 
313233 


CoM Re et te 





To change a source statement, you key the correction in the appropriate 
position on the line containing the statement. For example, to change STATE 
CODES to STATE ABBREV on line 0009.00 of the display shown here, you 
enter ABBREV on top of CODES. By entering SEU line commands over 
particular sequence numbers, you can insert, delete, resequence, or request 
prompting for specific source statements. 
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When you have completed modifying the source, you press the CF1 key. You 
receive the exit display. The edited source statements do not replace the actual 
source in the source member unless you select an option that updates the 
member, as in this example: 


SEU EXIT 


Select one of the following: 
L. Exit without uptime 


Exit and update venber I 
Exit and cresta « nber 


Update member, no exit 
. Create member, no exit 
Returr to edit screen 


a 


tion: _ 
ee Leal HEMBER FILE LIBRARY 


For option 2 to 5: MLG310 —s-«s@RPGSRC =: MLGLIBDEV_ 
Resequence member (Y N): XY Start: },00 Increment: 1,00 


For optiors 1 to 3: 
Return to member list (YN): N 


For options 1 to 6: 
Print source listing (YN): WN 


TOTAL RECORDS ADDED CHANGED DELETED SYNTAX ERRORS LEFT 
141 1 


In the following chapters, various programs and files will be created from 
source that has been entered through SEU. For more details on SEU and its 
use, refer to the SEU Reference Manual and User’s Guide. 


Chapter 6. Libraries and Files 


OVERVIEW 
In Chapters 3 and 4, all of the objects used were placed in a library named 
QGPL (general purpose library), which is the |BM-supplied default library. 
Putting all user objects in a single library is probably not typical of library use 
on the System/38, because it does not separate multiple applications. One use 
of libraries is to group objects that have something in common so that,. for 
example, the objects associated with each application are in separate libraries 
(which you define). Libraries can help you organize and control your system. 
This chapter discusses libraries and files as follows: 


e The basic concepts of libraries and library lists. 


e How to create a library and the basic objects needed for application 
development work. 


e Considerations for using the programmer menu after the application is 
developed. 


e The basic concept of a field reference file. 


e How to create the data base files used in the remainder of this publication. 
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LIBRARIES 


A library is a CPF object that serves as a directory to other CPF objects. It is 
used to group related objects and to find objects by name when they are used. 





On System/38, a library can contain objects of different types, including 
programs, source files, and other kinds of files. The name of an object must 
be unique for each object of a particular type within a library. For example, 
two files in the same library cannot have the same name, but a file and a 
program in the same library can have the same name. 


IBM supplies several libraries and you can use these along with libraries that 
you create. An example is shown below. 


User-Defined 


IBM-Supplied Library 


Library 


1BM 
Program Program 1BM-Supplied 


Library 














 OPRINT 
Output 
Queue 


The QSYS library contains IBM-supplied objects needed for the operation of 
CPF. The QGPL library contains IBM-supplied objects, such as the QBATCH 
job queue, to help you use the system, as well as objects created by the 
system users. RPG, COBOL, the Interactive Data Base Utilities (IDU), and the 
Conversion Reformat Utility also have their own libraries (QRPG, QCBL, QIDU, 
and QS3E). 


In the illustration above, there are two objects in the library USER1 named A. 
These names are valid because one object is a program and the other Is a file. 
Qualified Names and the Library List 


You can request an object on the system by stating a qualified name or by 
allowing the job's library list to be used. 





A name is said to be qualified when both the object name and the name of the 
library that contains the object are used, such as: 


A.USER2 


A period must separate the two names. If you use a qualified name when you 
request an object, only the library you specified is searched for the object. No 
other library is searched. 


A. USER2 







Library USER1 












Searched File A | 


ore 
SS 
Not 

Searched 





If a library contains two different object types having the same name, you must 
specify the object type or the object type must be implied in your request. For 
example, if you specify 


CALL B.USER2 


as in the following illustration, object types other than programs are ignored in 
the search of the library USER2, because the CALL command assumes that 
only a program object type is to be found. The CALL command is always 
followed by a program name, which is B in this example. The file named B is 
ignored. 


CALL B.USER2 


Searched 
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If a qualified name is not given when an object is requested, the system 
searches for the object by using the /ibrary list that is associated with the job 
in which the request was made. A library list is an ordered list of library names 
indicating which libraries are to be searched, and the order in which they are to 
be searched, to find an object. In commands and on displays, the library list is 
indicated by *LIBL. 


To use the library list to call program A in USER1, specify 
CALLA 


The first library, USER1, is searched for a program named A. Because program 
A is found in the first library, program A in USER2 is ignored. 







aerate eee ONL SP i 
| Library List! USER1 USER2 QGPL 
, ee SS er ea ee 
CALLA 
Search 
Order 





Library USER1 7 
as 


FieA LY 
Fite A. 2 os are. 





, 5 a a 
on 
pn i 


ene > 





If you specify 
CALL B 


the search starts in the first library, USER1. Because no program named B is 
found, the second library, USER2, is searched and the program is found. 


(ETAL Re I ET Oe ag 
- Library List: USER1 USER2 QGPL_ 
OES TS SEE Fee TERETE TENE 


CALL B 


Library USER1_ << § Order 


— i a a am | le 4 gs tt “in, "id ne 
La) as "1 1 ee 















rary USER2 
a a ee ee ee E ui. A Le Toy 
=< oo oe SE ae ee ee 
Program B ma 
= 7 se fe gl 
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The following illustration shows four sample libraries. 


i ist: USER1 USER2 QGPL 
Search Library List ' 


Order 









Library USER1 oe 
ee 








The libraries USER1, USER2, and QGPL are in the library list and the library 
USERS is not. If you specify 


CALL C.USER3 
the program C is found in USER3 because C.USER3 is a qualified name. 
lf program C needs to use file D and file D is not specified with a qualified 


name, the library list is used to find file D. The search is not successful 
because file D is in USER3, which is not in the library list. 
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RPG II! does not allow qualified names to be specified in a program. An 
override command can be used to specify a qualified name for some objects, 
but an easier approach is to specify all libraries that you will be using in the 
library list. If the library USER3 is added to the library list, as shown below, 
you can specify 


CALL C 


and both program C and file D will be found. 


“Library List; USER1 USER2 QGPL USER3 
oa BLibrary List; USER] USER2 GG 
Order 





Library USER1 


Library USER2 =. 























The Library List in Applications 


Each job in the system has its own library list. This library list consists of a 
system part and a user part, as in Figure 6-1. 


Lists libraries that 
contain objects needed 


by system. 
Library List 
Same for all jobs. 
Syste 
abs ™ asys 
Lists libraries that 
contain objects 
referenced by users. 
User QGPL 
Part Default list defined 
OQTEMP for all jobs. 


Default list overridden 
for individual jobs if 
separate library list 
specified for job, 





Figure 6-1. Job Library List 


Figure 6-1 shows the library list as shipped by IBM. The system part contains 
only the QSYS library; the user part contains only the QGPL and QTEMP 
libraries (for more details, see the CPF Programmer's Guide). 


Generally, only the user part is apparent to the system users because it affects 
objects they request in individual jobs. Therefore, the discussion of library lists 
in this publication is restricted to the user part of the library list. 


You can determine which libraries are contained in the user part of the library 
list for a job by issuing the Display Library List (DSPLIBL) command in the job. 
For example, you can use the programmer menu as follows to display the 
library list for your interactive job at a work station: 


PROGRAMMER MENU 
Select one of the following: 
. Design/execute DFU app (app), »(options) 
Design/execute query app (app), » (options ) 
. Create object object name, type, pgm for CMD, (text) 
. Call program program name 
Execute command command 
» Submit job {job name), Ccommand) 
Display submitted jobs 
. Edit source (srembr); (type), (text) 
. Design display format (srembr ) 
90. Sign off (*¥NOLIST *LIST) 


Types: BSCF, CBL, CL, CLP, CMD, CMNF, DSPF, LF, PF» PRIF» RPG, TXT 


Option: 5 Parm: Type: Parm 2: 


Command: dsplibl 


Text: Log requests: *YES 
Sre file: Sre lib: *LIBL Obj lib: Jobd: QBATCH 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPNSG 
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You receive a display of the following type: 


03731761) (6714206), USER LIBRARY LIST DISPLAY 

POSITION LIBRARY POSITION LIBRARY POSITION LIBRARY 
l QGPL | 
2 QTEMP 





This sample display shows that the library list being used for the job ts the 
default list. For many applications, this default library Jist may not be sufficient. 
For example, if the application references objects in the QRPG and QIDU 
libraries, those libraries should be included in the library list for each job using 
the application. If a reference is made to an object without specifying its 
library and the library is not in the job library list, the system will not be able to 
find the object. This will result in an error in the job. 


TO avoid this problem, you need to replace the default library list by a library 
list that includes all libraries containing objects referenced in the application. 
The new library list must be defined for all jobs using the application. 





Each application should have a method to define its own library list. For 
example, an interactive job that requests the mailing list application could first 
call a program that uses the Replace Library List (RPLLIBL) command to define 
the correct library list. For a batch job, the library list could be specified in one 
of the following ways: 


« The job description for the batch job contains an initial library list (INLLIBL 
parameter of Create Job Description command). 


« The Job or Submit Job command used to submit the batch job specifies an 
initial library list (INLLIBL parameter). 


« The batch job contains the RPLLIBL command, which specifies a new library 
list. 


Because it is desirable to specify a library list only once, a job description that 
contains a specific library list should be created for use by all batch jobs in an 


application. 


The new library list specified by the INLLIBL parameter or the RPLLIBL 
command overrides (completely replaces) the default user library list. 
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THE MAILING LIST LIBRARY AND STANDARD OBJECTS 


In the remaining application approaches, a user-created library named 
MLGLIBDEV (mailing library development) is used. It will be used to contain all 
of the objects created for the application. It is created from the programmer 
menu as follows: 


PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app)» »Coptions) 
2. Design/execute query app (app), »loptions) 
. Create object object names type» pgm for CMD, (text) 
Call program program name 
Execute command command 
Submit job (job name), (command) 
. Display submitted jobs 
. Edit source (srcmbr), (type), (text) 
Design display format (srembr ) 
Sign off (¥NOLIST *LIST) 


Types: BSCF, CBL, CL, CLP, CMD, CMNF, DSPF, LF, PF» PRIF, RPG, TXT 


9 ee) — 
Option: 5 Farm: — : 
“Command: grtlib lib(miali 


Log requests: *YES 


Src file: Sre lib: *LIBL Obj lib: Jobd: Q@BATCH 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPNSG 


Text: 





This library will contain standard objects that can be used in any application 
and objects associated only with the mailing list application. The standard 
objects that can be used in any application (and are required for the remaining 
approaches) are the following: 


e Source files 

¢ Job description 

e Set library list program 

This section describes how these standard objects are created and used. 

If this library will only be used for testing purposes, also specify TYPE(*TEST) 
in the CRTLIB command. Defining a library as a test library facilitates the use 


of debugging functions (not described in this publication; see the CPF 
Programmer's Guide). 











Source Files 


Four of the IBM-supplied source files, QCLSRC, QDDSSRC, OQRPGSRC, 
QUDSSRC, are used in this example. They are designed to contain source 
statements for items such as high-level language programs and DDS. 


The !BM-supplied source files could be used to contain all source; however, 
user-created source files are generally preferred because the source can then 
be controlled by application area. The names of the IBM-supplied source files 
will be used as the names of the user-created source files because the 
{BM-supplied source file names are defaults on various commands. Because 
the user-created source files will be in MLGLIBDEV, they can have the same 
names as the |BM-supplied source files, which are in |BM-supplied libraries. 


A QCLSRC file for CL program source is created as follows: 


PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app), s»s(Coptions) 
. Design/execute query app (app), »loptions) 
. Create object object name, type, pgm for CMO, (text) 
. Call program program name 
. Execute command command 
Submit job (job name), (command) 
Display submitted jobs 
. Edit source (srembr), (type), (text) 
. Design display format (srcmbr ) 
. Sign off (*NOLIST *#LIST) 





Types: BSCF, CBL, CLs; CLP, CMD, CMNF, OSPF, LF,» PF,» PRTF; RPGs TXT 


Option: 5 Parm: Type; _- Parm 2: 
Command: crtsrepf file(qclsrc.mlgqlibdev) text('ClL Source File’) 


Text: Log requests: *YES 
Src file: Src lib: *LIBL Obj lib: Jobd: QBATCH 
CF3-Command entry CF4-Prompt (3 & 5 only) CF&-~-DSPHNSG 





A qualified name (qclsrc.mlglibdev) is used for the file when it is created so 
that the file is placed in the correct library. 
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A QDDSSRC source file for physical file, logical file, and display file source is 
created as follows: 





PROGRAMMER MENU 
Select ane of the following: 
1. Design/execute DFU app (app), ,(options) 
2. Design/execute query app (app), »(options) 
3. Create object object name, type, pgm for CMD, (text) 
Call program program name 
. Execute command command 
Submit job (job name), (command) 
Display submitted jobs 
Edit source (srcmbr), (type), (text) 
Design display format (srcmbr ) 
Sign off (*NOLIST *LIST} 


Types: BSCF, CBL, CL, CLP, CHD, CMNF, DSPF, LF» PF, PRTF, RPG», TXT 


Option: 5 Parm: Type: Parm 2: 
Command: repf 3 strc.m ibdev) text('DDS Source File’ ) 


Text: Log requests: *YES 


Src file: Sre lib: *LIBL Obj lib: Jobd: QBATCH 
CF3-Command entry CF4-Prompt (3 & 5 only) | CF6-DSPMSG 





A QRPGSRC source file for RPG III program source is created as follows: 


PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app), » (options) 
2. Design/execute query app (app), »loptions) 
Create object object name, type, pgm for CMD, (text) 
Call program program name 
Execute command command 
Submit job (job name), (command) 
Display submitted jobs 
Edit source (srembr), (type), (text) 
Design display format (srcmbr ) 
Sign off (#NOLIST *LIST?) 


Types: BSCF, CBL, CL, CLP, CMO, CMNF, DSPF, LF, PF, PRTF, RPG» TXT 


Option: 5 Perms Medgar Pare 2: 
Command: ¢ertsar lglibdev) size(50 50 50 400) text('RPG Source 40 ext('RPG Source 


Texts Log requests: *YES 


Src file: —' Sre lib: #LIBL Obj lib: Jobd: QBATCH 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPMSG 





The values that are listed for the SIZE parameter will provide better storage 
allocation than the default values because RPG members normally contain 
more source statements than other types of members. 


A QUDSSRC source file for the utility definition statements for |DU 
applications is created as follows: 


PROGRAMMER MENU 
Select one of the following: 
Design/execute DFU app (app), , (options ) 
Design/execute query app (app); ,(options) 
Create object object name, type» pgm for CHO, (text) 
Call program program name 
Execute command command 
Submit job (job name), (command) 
Display submitted jobs 
Edit source (srembr), (type), (text) 
Design display format (srcmbr } 
Sign off (*NOLIST *LIST) 


Types; BSCF, CBL, CL, CLP, CMD, CMNF, DSPF, LF» PF, PRTF, RPG, TXT 


Option: 5 Perm: __ Type: Parm 2: 
Command: sr ile( ro.mlglibdev) text('U0S Sour ile’) 


Text: Log requests: *YES 


Sre file: Sre lib: *LIBL Obj lib: Jobd: QBATCH 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPNSG 





Libraries and Files 6-13 


Job Description 


Each job has a set of attributes that define how the system is to handle the 
job. Specifying all the attributes each time a job is submitted would be tedious 
and time-consuming. Because many jobs in an application have the same (or 
similar) attributes, CPF supports an object called a job description in which the 
attributes of a job can be predefined. When an application job is submitted, it 
need only reference the job description to ensure that the correct attributes are 
used. A job description named MLGLIBDEV will be created to control the 
execution of batch jobs in this application. Included in this job description is 
the library list to be used for the batch jobs. The job description is created as 
follows: 


PROGRAMMER MENU 
Select one of the following: 


1. Design/execute DFU app (app), »l(options) 

2. Design/execute query app (app), »foptions) 

3. Create object object name, type, pom for CMD, (text) 
4. Call program program name 

§. Execute command command 

6. Submit job (job name), (command) 

7. Display submitted jobs 

8. Edit source (srcembr), (type), (text) 

9. Design display format (srcombr ) 
90. Sign off (¥#NOLIST *LIST) 


Types: BSCF, CBL, CL, CLP, CMD, CHNF, OSPF, LF» PF, PRTF, RPG, TXT 


OQ: @o@ @ 








Option: 5 Parm: Type: 
Command : b ibdev mlqlib inlLlibl(mlqlibdev 1 atemp gidu arpa) 
. De ipti for Mailin ist' 
O rixt: Log requests: *YES 
Src file: Sre lib: MEIBL Obj Lib: Jobd: QBATCH 


CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPNSG 


A) The INLLIBL parameter specifies the initial library list so that MLGLIBDEV is the 
first library searched, followed by QGPL (general purpose library), QTEMP 
(temporary library), QIDU (IDU library), and QRPG (RPG library). 


oO A temporary library (QTEMP) is created at the beginning of each job and then 
deleted when the job is completed. 


Cc] The QIDU and QRPG libraries contain the !BM-supplied programs for the IDU and 
RPG Ill program products. 


® The LOG parameter defines the amount and type of information to be logged in 
the job log. 











Note that the user library, MLGLIBDEV, which contains the source files just 
defined, is specified before the |BM-supplied libraries, which contain the 
default source files. The libraries must be specified in this order for correct use 
of commands and the programmer menu. 


For each batch job that uses this job description, the library list specified in the 
INLLIBL parameter replaces the default user library list (see Figure 6-1). The 
application library, MLGLIBDEV, would not normally be included in the default 
library list. 


Because this application does not use COBOL or the Conversion Reformat 
Utility, the COBOL library (QCBL) and Conversion Reformat library (QS3E) are 
not included in the library list. You may need to include QCBL and QS3E in the 
library list for your applications. 


When the job description is created, default values are used for the job queue 
(QBATCH) and the output queue (OQPRINT). These defaults are used for all 
examples in this publication. 
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Set Library List Program 





The job description just created is used to replace the default library list for 
batch jobs executing in the application. Now, a CL program named SETLIBL 
will be created to replace the default library list in interactive jobs executing in 
the application. After you create this program, the Replace Library List 
(RPLLIBL) command does not need to be entered for each interactive job; 
however, the SETLIBL program must be executed each time you sign on to do 
an interactive job in this application. 


The following procedure can be used to create the SETLIBL program. 


Enter the RPLLIBL command as follows so that MLGLIBDEV is part of the 
library list and the system can find the job description entered in the next step. 


PROGRAMMER MENU 

Select one of the following: 

1. Design/execute DFU app (app), ;,loptions) 

2. Design/execute query app (app), ;(options) 
Create object object name, type, pgm for CMD, (text) 
Call pregram program name 
EXecute command command 
Submit job (job name), (command) 
Display submitted jobs 
Edit source (srembr), (type), (text) 
Design display format (srcmbr ) 
. Sign off (¥NOLIST *LIST) 


oOo On oun Sw 


2 


Types: BSCF, CBL» CL» CLP, CMD, CMNF, DSPF, LF, PF, PRTF, RPG, TXT 





Option: 5_ Parm: Type: Parm 2: 
Command: rpllibl liblimlglibdev l qtem idu_arpq) 


Text: Log requests: #*YES 
Src file: Src lib: #LIBL Obj lib: Jobd: QBATCH 
CF3-Command entry CF4-Prompt (3 £5 only) CF6-DSPMSG 








Now request SEU as follows: 


PROGRAMMER MENU 

Select one of the following: 

1. Design/execute DFU app (app), »lCoptions) 
. Design/execute query app (app), ;(options) 
. Create object object name, type, pgm for CMD, (text) 
. Call program program name 
Execute command command 
Submit job (job name), (command) 
. Display submitted jobs 
Edit source (srombr), Utype)s (text) 
Design display format (srembr ) 
. Sign off (*#NOLIST *LIST) 


owe wy omwmfwn 


.*) 


Types,. BSCF; ei CL, CLP, alas c Viale OSPF, LF, PF, PRTF, RPG, TXT 


Option: 8. Parm: SETLIBL Type: CLP. Parm 2: 
Command: 


Text: Set Library List Program for MLGLIBDEV Log requests: #YES 
Src file: Src lib: MLGLIBDEV_ Obj bib: MLGLIBDEV. Jobd: MLGLIBDEV 
CF3-Command entry CF4-@pnpt (3 & 5 only) @F6-ospnse 





Select option 8 to request SEU. 

Key in the name of the source member here. 

Key in the type here. 

You can key in text here to describe the source member. 

Once you have made these entries for Src /ib, Obj lib, and Jobd, they will remain 


on the menu, so that you do not have to enter them again for the remainder of 
your interactive job at the work station. 


ooo 0 6 


The source library (Src /ib) must be specified when option 1, 2, 3, 8, or 9 is selected 
on the programmer menu. The object library (Obs /ib} must be specified when 
option 3 or 4 is selected. However, if you create an object by selecting option 5, 
you must specify the library MLGLIBDEV as you did when you created the 
MLGLIBDEV job description. A job description (Jobd) must be specified when 
option 3 or 6 is selected. MLGLIBDEV is keyed in as the source library, the 
object library, and the job description (which you previously created). A source 
file (Src fife} name is not selected because the default file names (such as OCLSRC) 
will be used. 
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SETLIBL is now a member of QCLSRC and space is allocated for the source 
statements. An SEU edit display appears that allows you to enter the source 
statements as follows: 


SEU US W:l Mbr: SETLIBL Scan: 
FMT #00. fe Ll cee coe Bice e cee B cee cee 4 cee cee BS cue cee © one 
@Q *#¥**BEGINNING OF DATAH#3% 
0001.00 PGM /* SETLIBL REPLACE LIBRARY LIST PROGRAM FOR MLGLIBDEV*/ 
0002.00 RPLLIBL LIBL(MLGLIBDEV QGPL QTEMP QIDU QRPG) 
G 003. 00 ENDPGM 
MHSMHEREND OF DAT A006 9696060638 


The PGM command begins a CL program. 


© © 


Any job that calls this program will have its library list replaced as defined by this 
RPLLIBL command. 


@ _ = The ENDPGM command identifies the end of the program. 








After you enter the source statements as shown and exit SEU, the programmer 
menu reappears. The program SETLIBL can now be created as an object 
within MLGLIBDEV by using the programmer menu as follows: 


PROGRAMMER MENU 

Select one of the following: 

1. Design/execute DFU app (app), »(options) 

2. Design/execute query app (app), »(options) 
Create object object name, type, pgm for CMD, (text) 
Call program program name 
Execute command command 
Submit job {job name), (command) 
. Display submitted jobs 
. Edit source (srcmbr), (type), (text) 
. Design display format (srcmbr ) 
. Sign off (¥NOLIST *LIST) 


Onan & ul 


0 
oOo oO 


Types: BSCF, CBL, CL, CLP, CMD, CMF, DSPF, LF, PF, PRTF, RPG, TXT 


Option: 3. Parm: SETLIBL Type: CLP Parm 2: 


Commandtet 


Se 

Text: Set Library List Program for MLGLIBDEV Log requests: *YES 

Src file: ; Sre lib: MLGLIBDEV. Obj lib: MEGLIBDEV_ Jobd: MLGLIBDEV 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPHSG 





You only need to enter a 3 (for option) because all of your other previous 
entries still appear on the programmer menu. The entry in the option field 
disappears after each requested function is complete, but all other entries 
remain. 


All create operations that result from selecting option 3 are submitted as batch 
jobs. Input at the work station is not inhibited while an object is being created. 


Note the difference between selecting option 3, which was used to create the 
SETLIBL program, and selecting option 5, which was used to create the job 
description. Option 5 requires the entire command, including the name of the 
library that contains SETLIBL, to be keyed in. The command is executed 
immediately when the Enter key is pressed. Option 3 requires only a few 
parameters to be keyed in. When the Enter key is pressed, the command is 
submitted for execution as a batch job. The system uses the source and object 
library names keyed in at the bottom of the programmer menu to generate the 
correct create command and place it as a batch job on the job queue. SETLIBL 
is created by the batch job and is placed in MLGLIBDEV. The library 
MLGLIBDEV is now ready to contain specific application objects. 
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Programmer Menu Considerations 


Each time you are ready to work on the mailing list application, you can define 
your own library list from the programmer menu as follows: 


PROGRAMNER MENU 
Select ofte of the following: 
1. Design/execute DFU app (app), »Coptions) 
2. Design/execute query app (app), ,»(options) 
3. Create object object name, type, pgm for CMD, (text) 
4. Call program program name 
5. Execute command command 
6. Submit job {job name), (command) 


7. Display submitted jobs 

8. Edit source {srembr), (typed, (text) 
9. Design display format (srembr ) 

90. Sign off (#NOLIST *LIST) 


Types: BSCF, CBL, CL, CLP, CMD, CMNF, DSPF, LF» PF, PRTIF, RPG, TXT 


Option: § Pura: = Type Parm 2: 
Command: cal] _setlibl. miglibdev (@y 


Text: 3. Jaa es Log requesta: AYES 
Src file: Src lib: MLGLIBDEY Oj lib: HMLGLIBDEV. Jobd: MLGLIBDEV 
CF3-Command entry CF4-Promt (3-8 @pnly)  CF6é-DSsPHSG @ 





@ = These entries call the SETLIBL program, which replaces your library list. 


re) These entries are made once per work station job. 


The MLGLIBDEV entries that are made once establish the environment for 
application development and maintenance. It is assumed that you have 
established the environment for the remaining application approaches in this 
publication. 


This section describes a typical programmer task and shows how the 
programmer menu can be used to perform this task. Assume that source for 
an RPG III program named MLG600 has been previously entered. The source 
must now be changed for one of the following reasons: 


« The program did not compile because the RPG compiler found errors in it. 


The program did not execute as expected. 
« Record formats have changed. 


- The program is being enhanced. 











To change the source, you request SEU by making the following entries on the 
programmer menu: 


PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app), »Coptions) 
2. Design/execute query app (app), »loptions) 
3. Create object object name, type, pgm for CMD, (text) 
4. Call program program name 
5. Execute command command 
Submit job (job name), (command) 
Display submitted jobs 
Edit source (srembr), (type), (text) 
Design display format (srembr ) 
Sign off (#NOLIST *LIST) 


Types: BSCF, CBL, CL, CLP, CMO, CMNF, DSPF, LF, PF, PRTF, RPG, TXT 


Option: 8 Parm: MLG600 Type: RPG Parm 2: 


Command: 


Text: Log requests: *YES 
Sre file: Sre lib: MLGLIBDEV Obj lib: MLGLIBDEV. Jobd: MLGLIBDEY 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPHSG 





You receive an SEU display that shows the source statements (see Source 
Entry Utility in Chapter 5). After you make the required changes and exit SEU, 
the programmer menu reappears. It looks like the previous display (with the 
entries on it) except the option field is blank. 


If you try to use option 3 to create MLG600 and a program named MLG600 
already exists in MLGLIBDEV, the following error message appears: 


PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app), ,loptions) 
2. Design/execute query app (app), ,loptions) 
3. Create object object name, type, pgm for CMD, (text) 
4. Call program program name 
5. Execute command command 
6. Submit job (job name), (command) 
7. Display submitted jobs 
8. Edit source (srcmbr), (type), (text) 
9. Design display format (srembr ) 
90. Sign off (H#NOLIST #LIST) 


Types: BSCF;, CBL, CL, CLP, CHO, CMNF, DSPF, LF, PF, PRTF, RPG» TXT 


Option: 3. Parm: MLG600 Type: RPG Parm 2: 


Command: 


Text: Log requests: *YES 


Sre file: Sre lib: MLGLIBDEV. Obj lib: MLGLIBDEV. Jobd: MLGLIBOEV 
CF3-Command entry CF4-Prompt (3 &5 only) CFé-DSPMSG 


Object already exists. Press CF11l to replace existing object. 
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The existing program named MLG6O00 must be deleted before the new 
program named MLG6O0 can be created. This can be done by replacing the 
existing MLG600 with the new MLG600 as follows: 


1, Press the Error Reset key to remove the error message and allow input. 
2. Press CF11 to delete the existing object and then create the new object. 


If you did not intend to give the two objects the same name and do not want 
to replace the existing object, press the Error Reset key, change the request, 
and press the Enter key to enter the new request. 


Another way to replace an object is to select option 3 and then press CF11 
(instead of pressing Enter). This means that the object you specified should be 
replaced if it exists. No error message is displayed. 


When some objects are created for the final production version, you may want 
to specify certain parameters on the Create commands instead of using 
defaults. You can use command prompting to help you do this from the 
programmer menu. When option 3 is selected, press CF4 to display the 
prompt. Specific options can then be selected and the modified Create 
command is submitted as a batch job. 











Each time a request to create an object is submitted by selecting option 3, that 
request becomes a job. Submitted jobs can be reviewed by selecting option 7 
on the programmer menu. You receive a display of the following type: 


04/22/60 11:19:33 SUBMITTED JOBS - Q@BATCH 
JOB NAME USER NBR TYPE STATUS 
_ MiLG600 QPGMR 004248 BATCH ACTIVE 


1-DSPJOG 2-Spl files 4-HLDJOB 6-RLSJOB 9-CNLJOB CF5-Redisplay 


While the submitted Job is on the job queue or is being compiled, the 
programmer can be working in the same or a different application area. When 
the compilation is finished, a message saying whether or not the compilation 
was successful is sent to the work station. Press CF6 from the programmer 
menu to display messages. 


The compilation listing produced by the compiler can be displayed at the work 
station and/or printed. System/38 allows all programmer functions to be 
performed without using paper output. A full discussion of this technique is 
beyond the scope of this publication. 
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FILES 


The following three types of files are needed for the interactive approaches in 
Chapters 7 through 11: 


« Field reference file 
« Master files 
« Transaction files 


This section discusses these objects and shows how to create them. 


Field Reference File 
A field reference file is a physical file whose record format describes the fields 
used by a group of files. A field reference file contains no members (data 
records). The field descriptions in the field reference file can be referred to 
when the DDS for other files are written. Some benefits of using a field 


reference file are: 


« It is a single source for all field information (Such as attributes and text 
description). 


« it allows using a reference to a previously described file. 
« l|t improves documentation throughout the files and programs. 


« It simplifies the coding needed to achieve consistency and documentation. 











The field reference file named MLGREFP contains the record format for the 


mailing list example. To enter the source for MLGREFP, request SEU from the 
programmer menu as follows: 


PROGRAMMER MENU 

Select one of the following: 

1. Design/execute DFU app (app), sloptions) 
. Design/execute query app Capp), ,(options) 
. Create object object name, type, pgm for CMD, (text) 
. Call program program name 
Execute command command 
. Submit job (job name), (command) 
Display submitted jobs 
Edit source (srembr), (type), (text) 
. Design display format (srembr ) 
Sign off (¥NOLIST *LIST) 


C0: Sa See 


0 


Types: BSCF, CBL, CL, CLE CMD, CMHNF ga 9SPF, LF» PF» PRIF» RPG» TXT 
© o 


Option: 8 Parm: MLGREFP Type: PF Parm 2: 
Command: 


Text: Mailing List Field Reference File Log requests: *YES 


Src file: . Src lib: MLGLIBDEY Obj lib: MLGLIBDEV Jobd: MLGLIBDEV 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPHSG 





A The name keyed in for srcmbr (MLGREFP) is normally the same as the name for 
the file that will be created (MLGREFP). Using the same name helps control 
source and object relationships. 


Gs Because you indicated that the type is a file (a physical file in this case), the 
source will be placed in QDDSSRC. 


You receive an SEU display that allows you to enter the DDS source for 
MLGREFP. The DDS to be entered are shown in Figure 6-2. 
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Figure 6-2. DDS for MLGREFP Field Reference File 
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Each field uses the COLHDG keyword to define a column heading that is used 
by IDU. If the TEXT keyword is not defined for a field, the column heading is 
used as the text description (which is also used by IDU). This description also 
appears on the RPG [II compilation listing when the described field is copied as 
part of an externally described file. 


The descriptive information (COLHDG and TEXT) is entered in both uppercase 
and lowercase letters. SEU usually changes lowercase entries to uppercase. 
However, if you press the CF12 key, SEU will not change lowercase to 
uppercase; your entries will remain either lowercaSe or uppercase exactly as 
you key them in (vou press the Shift key for uppercase). When uppercase and 
lowercase information is printed on a system printer, an optional print belt is 
available for printing both uppercase and lowercase. If a print belt containing 
only uppercase letters is mounted, System/38 translates the lowercase letters 
so that they are printed as uppercase letters. This is the default for 
IBM-supplied files. 


The ADDR and CITY fields are defined by a reference function: R in position 
29 and REFFLD beginning in position 45. The reference function allows a field 
to be defined the same as a previously defined field. In this example, the 
ADDR and CITY fields are defined the same as the NAME field. If the size of 
the NAME field changes, the size of the ADDR and CITY fields automatically 
changes within the field reference file. The transaction fields (those fields 
whose names begin with X), also shown in Figure 6-2, are defined by the 
reference function. The transaction fields each have unique names because 
RPG requires unique storage areas to have unique names. 


The TRNNUM field contains the transaction number. This is a consecutive 
number which will be assigned by the data file utility (DFU). 


The MLGLK?1 field is used in a later approach and will be explained then (see 
Chapter 11). 


The EDTCDE keyword is used on most of the numeric fields to define the 
proper editing of the field. This is the default when the field is displayed or 
used by DFU or by Query. The edit code X for the ZIP field means that no 
editing will be performed and is used to prevent any default editing that may 
be applied by DFU or Query. The edit code Z is used to suppress the leading 
zeros in the ACTNUM, BATNUM, and TRNNUM fields. Edit codes are 
described in the CPF Reference Manua!l—DDS. 


When you have entered all the source shown in Figure 6-2, and exit SEU, the 


programmer menu is displayed again. MLGREFP is now a member of the 
source file as shown in Figure 6-3. 
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Figure 6-3. QDDSSRC Contains Member MLGREFP, which Contains DDS Source Statements 
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The physical file MLGREFP can now be created using the source in member 
MLGREFP of file QDDSSRC (Figure 6-3). Because you previously entered the 
name (MLGREFP) and the type (PF) on the programmer menu when you 


entered the source, you need only enter a 3 for the option number to create 
MLGREFP: 


PROGRAMMER MENU 

Select one of the following: 

1. Design/execute DFU app (app), ,loptions) 
. Design/execute query app (app), ,loptions) 
. Create object object mame, type, pgm for CMD, (text) 
Call program program n&éme 
Execute command command 
. Submit job (job name), (command) 
. Display submitted jobs ; 
Edit source (srembr), (type); (text) 
. Design display format (srembr ) 
. Sign off (*NOLIST *LIST) 


oOo On OWS Pa 


Oo 


Types: BSCF, CBL, CL; CLP; CMD, CMNF, DSPF, LF» PF, PRTF, RPG, TXT 


Option: 3. Parm: MLGREFP Type: PF Parm 2: 
Command: 


Text: Mailing List Field Reference File Log requests: YES 
Sre file: Sre lib: MLGLIBDEV Obj lib: MLGLIBDEV. Jobd: MLGLIBDEV 


CF3~Command entry CF4-Prompt (3 & 5 only) CF6-DSPMSG 





Libraries and Files 


6-29 


Master Files 


The master files used in the mailing list application are a physical file, 
MLGMSTP, and a logical files MLGMSTL. MLGMSTP contains the master data 
for the mailing list application and MLGMSTL provides the format and access 
path to access the master data. Accessing the master data through a logical 
file can help you achieve data independence. 





One of the advantages of System/38 data base support is the ability to 
achieve data independence. This means that any program using a specific 
record format does not need to be recompiled if changes occur to the physical 
data format but not to the logical record format used by the program. For 
example, if a field is added to the file such that the locations of some of the 
original fields are changed, the existing programs can be used without being 
recompiled. Refer to the CPF Programmer's Guide for information on how to 
do this. 


Because MLGMSTL is a logical file used to access the data in MLGMSTP, the 
definition for MLGMSTP must be created first. To enter the source for 
MLGMSTP, you request SEU from the programmer menu as follows: 


PROGRAMMER MENU 
Select one of the following: 
- Design/execute DFU app (app), » (options) 
- Design/execute query app (app), ,»loptions) 
- Create object object name, type, pgm for CMD, (text) 
- Call program program name 
Execute command command 
- Submit job (job name), (command) 
Display submitted jobs 
Edit source (srcmbr), (type), (text) 
Design display format (srcmbr ) : 
Sign off (*NOLIST *LIST) 





Seo On ruff wn = 


wo 


Types: BSCF, CBL, CL, CLP, CMD, CMNF, DSPF, LF, PF, PRTF, RPG, TXT 


Option: 8 Parm: HLGMSTP Type: PF Parm 2: 


Command: 


Text: Majling List Master Physical File Log requests: *YES 
Src file: Sre lib: MLGLIBOEV. Obj lib: MLGLIBDEV_ Jobd: MLGLIBDEV 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPMSG 





You receive an SEU display that allows you to enter the DDS source for 
MLGMSTP. The DDS to be entered are shown in Figure 6-4. The REF 
keyword specifies the field reference file (MLGREFP) previously created. An R 
In position 29 specifies that the field reference function is being used. This 
tells the system to copy the complete description of the field (including 
COLHDG and TEXT) from the field reference file. No key field is specified for 
this file. 
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Figure 6-4. DDS for MLGMSTP File 





When you exit SEU after entering the DDS for MLGMSTP, the prograrnmer 
menu is displayed again. To create the physical file MLGMSTP, you need only 
select option 3: 


PROGRAMMER MENU 
Select one of the following: 


1. Design/execute DFU app (app), ;€options) 

2. Design/execute query app (Capp), ,loptions) 

3. Create object object name, type, pom for CMD, (text) 
4. Call program program name 

5. Execute command command 

6. Submit job (job name), (command) 

7. Display submitted jobs 

8. Edit source (srembr), (type), (text) 

9. Design display format (srembr ) 
90. Sign off (*NOLIST *LIST) 


Types: BSCF, CBL, CL, CLP, CMD, CMNF, DSPF, LF» 


Option: 3. Parm: MLGMNSTP Type: PF Parm 2: 
Command: 


Text: Mailing List Master Physical File Log requests: ¥YES 
Sro file: Sre lib: MLGLIBDEV. Obj lib: MLGLIBDEV Jobd: MILGLIBDEY 


CF3-Command entry CF4-Prompt (3 & 5 only) 


PF, PRTF, RPG, TXT 


——<—sa= me ee 
——7 


CF6-DSPMSG 
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Now, the definition for MLGMSTL its created. You request SEU from the 
programmer menu as follows: 


PROGRAMMER MENU 

Select one of the following: 

1]. Design/execute DFU app (app), »Coptions) 
. Design/execute query app (lapp)» ;loptions) 
. Create object object name, type, pgm for CMD, (text) 
. Call program program name 
. Execute command command 
Submit job {job name), (command) 
. Display submitted jobs 
Edit source (srembr), (type), (text) 
Design display format (srcmor ) 
Sign off (*NOLIST *LIST) 


oo On omPfu nr 


~o 


Types: BSCF, CBL,; CL, CLP, CMD, CHNF, OSPF, LF, PF, PRTFs RPG, TXT 


Option: 8 Parm: MLGMSTL Type: LF Parm 2: 


Command: 


Text: Mailing List Master Logica} File Log requests: *YES 
Src file: Sre lib: MLGLIBDEV Obj lib: MLGLIBDEV. Jobd: MLGLIBDEV 
CF3-Command entry CF4-Prompt {3 & 5 only) CF6-DSPNSG 





You receive an SEU display that allows you to enter the DDS for MLGMSTL. 
The DDS to be entered are shown in Figure 6-5. 
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Figure 6-5. DDS for MLGMSTL File 


The keyword UNIQUE specifies that duplicate key values are not allowed 
within a member of this logical file. The keyword PFILE identifies the physical 
file containing the data to be accessed through this logical file. Because 
individual fields are not specified for the logical file record format, the fields 
will be the same as the physical file MLGMSTP (see Figure 6-4). The K in 
position 17 identifies ACTNUM as a key field. 


After the source for MLGMSTL is entered, the logical file MLGMSTL can be 
created by selecting option 3 on the programmer menu: 


PROGRAMMER MENU 


Select one of the following: 





1. Design/execute DFU app (app), sloptions } 
2. Design/execute query app (app), ;»,(options) 
3. Create object object name, type, pgm for CMD, (text) 
4. Call program program name 
5. Execute command command 
6. Submit job (job name), (command) 
7. Display submitted jobs 
8. Edit source (srcmbr), (type), (text) 
9. Design display format (srcmbr ) 
90. Sign off (¥NOLIST *LIST) 
Types: BSCF,; CBL, CL, CLP, CMD, CMNF, OSPF, LF, PF, PRTF» RPG, TXT 
Option: 3. Parm: MLGMSTL Type: LF Parm 2: 
Command: 
Text: Mailing List Master Logical File Lag requests: YES 
Src file: Src lib: MLGLIBDEV Obj lib: MLGLIBDEV Jobd: MLGLIBDEV 


CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPNSG 


Transaction Files 


The transaction files are a physical file, MLGTRNP, and a logical file, 
MLGTRNL. MLGTRNP contains transactions to be applied to the mailing list 


master file. MLGTRNL provides the access path to the transaction data. 


MLGTRNP is created first. Request SEU from the programmer menu as 


follows: 


PROGRAMMER MENU 


Select one of the following: 
1. Design/execute DFU app 
2. Design/execute query app 


{app), »(options) 
(app), ; (options) 


3. Create object object name, type, pgm for CMD, (text) 
4, Call program program name 
5. Execute command command 
6. Submit job (job name}, (command) 
7. Display submitted jobs 
8. Edit source {srcembr), (type), (text) 
9. Design display format (srcembr } 
90. Sign off- (XNOLIST ¥LIST) 
Types: BSCF, CBL, CL, CLP, CMD, CMNF, DSPF, LF, PF, PRTF, RPG, TXT 
Option: 8&8 Parm: MLGTRNP Type: PF Parm 2: 
Command: _ . 
Text: Mailing List Transaction Physical File log requests: *YES 
Sre file: Src lib: MLGLIBDEV. Obj lib: MLGLIBDEV Jobd: MLGLIBDEV 


CF3-Command entry CF4-Prompt (3 & 5 only) 


CF6-DSPHSG 


oe) 
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You receive an SEU display that allows you to enter the DDS for MLGTRNP. 
The DDS to be entered are shown in Figure 6-6. 
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‘sgure 6-6. DDS for MLGTRNP File 


A record format (MLGTRNBR) is defined with the same field names that were 
used in the transaction records discussed in Chapter 4. A transaction number 
(TRNNUM) field is added; this field will contain a consecutive number assigned 
by DFU. The keyword REF and the R in position 29 specify that the fietd 
reference file is used. 





After the DDS for MLGTRNP are entered, the physical file MLGTRNP can be 
created by selecting option 3 on the programmer menu: 


PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app); »(options) 
2. Design/execute query app (app), »loptions) 
3. Create object object name, type, pgm for CMD, (text) 
4. Call program program name 
5. Execute command command 
6. Submit job (job name); (command) 
. Display submitted jobs 
Edit source (srembr), (type), (text) 
Design display format (srombr ) 
90. Sign off (*NOLIST *LIST) 


Types: BSCF, CBL, CL, CLP, CMD, CMNF, DSPF, LF, PF, PRTF; RPG; TXT 


Option: 3 Parm: MLGTRNP Type: PF Parm 2: 
Command: 


Text: Mailing List Transaction Physical File Log requests: *YES 
Src file: Src lib: MLGLIBDEV. Obj lib: MLGLIBDEV. Jobd: MLGLIBDEV 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPMSG 





Now MLGTRNL can be created. Request SEU as follows: 


PROGRAMMER MENU 
Select one of the following: 
. Design/execute DFU app (app); »foptions) 
. Design/execute query app (app); ;(options) 
. Create object object name, type, pgm for CHD, (text) 
» Call program program name 
Execute command command 
. Submit job (job name), (command) 
. Display submitted jobs 
. Edit source (srembr), (type), (text) 
Design display format (srembr ) 
. Sign off (*NOLIST *LIST) 


ooo~n fru Sf wh = 


oO 


Types: BSCF, CBL, CL, CLP, CMD, CMNF, DSPF, LF, PF» PRTFs RPG» TXT 


Option: 8 Parm: MLGTRNL Type: LF Parm 2: 
Command: 


Text: Mailing List Transaction Logical File Log requests: #YES 
Src file; : Sre lib: MLGLIBDEV. Obj lib: HMLGLIBDEV Jobd: MLGLIBDEV 


CF3-Command entry CF4-Prompt (3 & 5 only? CF6é-DSPMSG 
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You receive an SEU display that allows you to enter the DDS for MLGTRNL. 
The DDS to be entered are shown in Figure 6-7. 
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Figure 6-7. DDS for MLGTRNL File 


The PFILE keyword specifies the format (MLGTRNP) over the physical data. 
The K in position 17 identifies TRNNUM as a key field. Because the DDS do 


not specify individual fields for the logical file record format, the fields will be 
the same as in the record format of the physical file MLGTRNP (see Figure J 
6-6). 


After the DDS for MLGTRNL are entered, the logical file MLGTRNL can be 
created by selecting option 3 on the programmer menu: 


PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app), »Coptions) 
2. Design/execute query app (app), »(options) 
3. Create object object name, type, pgm for CMD, (text) 
. Call program program name 
. Execute command command 
. Submit job (job name), (command) 
. Display submitted jobs 
. Edit source (srembr), (type), (text) 
. Design display format (srembr ) 
90. Sign of f (¥NOLIST *LIST) 


Types: BSCF, CBL, CL, CLP, CMD, CHNF,; DSPF; LF, PF, PRTF; RPG, TXT 


Option: 3. Parm: HMLGTRNL Type: LF Parm 2: 
Command? 


Text: Mailing List Transaction Logical File Log requests: *YES 
Src file: Src lib: MLGLIBDEV. Obj lib: MLGLIBDEY Jobd: MLGLIBDEV 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPMSG 
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A Review of Files and Their Usage 


When you create files for an application, they must be created in a definite 
sequence: 


« If a field reference file is to be used, it must be created before any physical 
files are created. 


« Physical files must be created before any logical files that use them are 
created. 


« Externally described data files must be created before the program that uses 
them is created. 


A field reference file will normally grow as an application is developed. 
Changes to the field reference file do not require that physical and logical files 
be re-created unless the change impacts the physical and logical files. 

A summary of the files used by this application at this point follows. 

When you define files, all of the files shown below are used and they must be 


created in the correct sequence. When the logical files are created, the field 
reference file is not used. 


When Defining Files 









MLGREFP 
Field 

Reference 
File 






MLGTRNP 
Physical 
Transaction 


MLGMSTP 
Physical 
Master File 











MLGMSTL 
Logical 
Master File 


Logical 
Transaction 
File 
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When you create programs, only the externally described files are used, as 
shown below (MLG311 will be discussed and used in Chapter 7). Note that 
the field reference file, physical files, or program described output file 
(QPRINT) are not used. 


When Creating Programs 


MLGMSTL MLGTRNL 
Logical 


Logical 
Master File 


MLG311 
RPG III 
Maintenance 
Program 





When you execute programs, all of the files except the field reference file are 
used, as shown below. 


When Executing Programs 


MLGTRNP 
Physical 


MLGMSTP 


Physical 
Master File 


rf 


Transaction 





ry 
i 
i sf 
Lt 
f 
£f 






MLGTRNL 
Logical 

Transaction 
File 











MLGMSTL 
Logical 
Master File 








MLG311 
RPG III 
Maintenance 
Program 


OPRINT 
Output 
File 














Chapter 7. Interactive Input and Batch Maintenance 


OVERVIEW 


In the pervious approach of Chapter 4, master records in a data base file were 
updated from transaction records that were read from diskette. The approach 
in this chapter allows transactions to be entered from a work station into a 
data base transaction file. The group of records entered into the transaction 
file is then applied to the data base master file by a maintenance program. 


The transaction entry part of this approach consists of the following: 


« A work station user enters transactions using a DFU application, MLG110U. 


« The transaction records entered at the work station are stored in the 
physical transaction file, MLGTRNP. A logical transaction file, MLGTRNL, 
provides the access path between the MLG110U application and the 
physical transaction file. 
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The maintenance part of this approach consists of the following: 


« A work station user invokes the RPG II] maintenance program, MLG311, by 
submitting a batch job that calls MLG311. 


The MLG311 program takes the records from the transaction file and 
applies them to the master file. A logical transaction file, MLGTRNL, 
provides the access path between the MLG311 program and the physical 
transaction file, MLGTRNP. Similarly, a logical master file, MLGMSTL, 
provides the access path between the program and the physical master file, 


MLGMSTP. 
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Call MLG311 










“RPG 
» ~ Maintenance 
Program Logical 
Master 








* MLG311 


OQPRINT 


Physical 
Master 








ENTERING TRANSACTIONS 


In Chapter 4, the transaction records were on diskette, and the fields of a 
record were described on input specifications for the RPG III maintenance 
program. In this approach, transactions are entered at the work station into a 
data base file, MLGTRNP, which also contains a description of the record 
format. 


The transactions are placed in MLGTRNP by a data file utility (DFU) 
application, MLG110U. DFU is the part of the IDU that is used to create, 
maintain, and display records in a data base file. A DFU application for a 
particular file (in this case, a transaction file) is created by responding to a 
series of prompts. That file must be an externally described data file and must 
be processed in keyed sequence, that is, based on the contents of key fields 
contained in the records. 
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MLG110U 
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Cc DFU Definition Cc 


Creating the DFU Application 


The first step in implementing this approach is to create the DFU application, 
MLG110U, so that a work station user can enter transactions into the 
transaction file. 


When creating or executing DFU applications, you may find the Keyboard 
Template (GX21-7756) useful. This set of templates identifies command 
function keys available for DFU, as well as for CPF, query, SDA, and SEU. 









Review 
Application 


‘ ° J 
Revigw 
Format 
Fields 
CF6é CFB cF9 CcF10 CFTt 

Pravious Display Add Add Advance Deleta/ 
Display Messages Before After an Change 
Owner 












cF22 
Review i i Nullity 
Application Detection Next on 
Fields On/Oft Format 
CFs CFi0O 
Previous Add Change 
On/Oftt On/Off 
7 
7 



















To create the DFU application MLG110U, you request DFU from the 
programmer menu as follows: 


PROGRAMMER MENU 

Select one of the following: 

1. Destgn/execute DFU app (app), »foptions) 
. Design/execute query app (app), »foptions) 
. Create object object name, type, pom for CMO, (text) 
- Call program program name 
Execute command command 
- Submit job (job name), (command) 
Display submitted jobs 
. Edit source (srcembr), (type), (text) 
Design display format (srembr ) 
. Sign off (¥NOLIST *LIST) 


eonxznrmnf wn 


0 


Types: BSCF, CBL, CL, CLP, CMD, CMNF, DSPF, LF, PF, PRTF, RPG, TXT 


Option: } Parm: MLG110U Type: Parm 2: 
Command: 


Text: Log requests: *YES 
Src file: Sre lib: MLGLIBDEV. Obj lib: MLGLIBDEV Jobd: MLGLIBDEV 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPMSG 
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You receive the DFU menu. Because you want to create an application, you 
select option 1 on this menu: 


DFU MENU 


Select one of the following: Gury. 
1. Create or change an application — 


2. Execute an application 
3. Manage existing application 


Option: 1 


Press HELP for instructions. Press CFl to exit. 





When you press the Enter key, you receive the DFU create/change menu: 


DFU CREATE/CHANGE MENU 


Select one of the following and enter values below: 
1. Display information about an application 
2. Create a new application 
3. Change an existing application 
4. Delete an existing application 


Option: 


Application name: (*#-Application selection List) 
Library name: 


HELP-Help CF2-Previous display 





& Select option 2. 


B The application name and library name are already filled in because you specified 
an application name and object library on the programmer menu. 
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You then receive the DFU create prompt. You use this prompt to specify the 
text description of the application you are creating and the file you want the 
application to access: 


DFU CREATE PROMPT 
Application name: MLG110U Library: MLGLIBDEV 


Enter information for new application: 


Description: DFU Program for Mailing List Transaction File 


File name: MLGTRNL (4-File salaction list) 
Library name: G@ptietippev 


HELP-Halp CF2-Previous display CF3-File information 


@) Key in the text description of the application. 


8 Key in the name of the file to be accessed and the library where the file is 
located. 


For the file name, you specify the name of the logical transaction file, 
MLGTRNL. The DFU application will interact with the records in the physical 
transaction file, MLGTRNP, through the access path defined by MLGTRNL 
(the procedures for creating MLGTRNP and MLGTRNL were discussed in 
Chapter 6). 
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When you press the Enter key after completing the create prompt, you receive 
the application control prompt. You only need to specify the size of the display 
screen you want the application to execute on: 


: ; APPLICATION CONTROL PROMPT 
Application name: MLG1L10U Library: MLGLIBDEV 
File name: MLGTRNL Library: MLGLIBDEV 


Place an X next to the display size: 
Primary display size: Ail X 24X80 12X80 16x64 


Take defaults after field selection: B N (Y-Yes N-No) 


HELP-Help CF2-Previous display 





A) Key in X if not shown here. 


@ Do not change this default value because you will need to modify the definitions. 


A file review prompt is displayed next: 


FILE REVIEW PROMPT FOR FILE HLGTRNL GD 


For each record format to be used, enter R to review the fields, A to select all 
fields, or E to enter the fields later: 
- . RECORD FMT DESCRIPTION 

R MLETRNR Mailing List Transaction, 


o °G © 





You specified this file name on the DFU create prompt. 
Key in R to review all fields. 


This record format was entered as part of the DDS for MLGTRNL. 


o 
o 
© 
oO 


This information was entered as part of the DDS TEXT keyword for the record 
format MLGTRNR. 











To respond to this display, you can enter R, A, or E on the blank line preceding 
MLGTRNR. By entering A, you specify that you will be entering data into all 
fields and the field review prompt is skipped. 


By entering E, you will bypass the field review prompt. These fields must be 
added later on the basic field definition prompt. 


By entering R, which is the option used for this example, you can review the 
fields for records in MLGTRNL. (This information was entered in the DDS for 
MLGTRNL, as discussed in Chapter 6.) The following field review prompt is 
displayed: 


FIELD REVIEW PROMPT FOR RECORD HLGTRNR 


Place an X next to each field to be used or enter *ALL: *#ALL © 
FIELD NAME. LENGTH TYPE DESCRIPTION 
BATNUM 6,0 Batch Number 
TRNTYP 1 Trans Type A=Add C=Change D=Delete 
XACTNM 5,0 Account Number 
XACTTP 1,0 Acct Type 1=Bus 2=Gvt 3=Org 4=Sch 5=Pvt 9=O0th 
XNAME 18 Name 
XADDR 18 Address 
XCITY 18 City 
XSTATE 2 State 
XZIP 5,0 Zip Code 
5,9 Transaction Number 


uUuU}YTF},?>yr Pr UVP U 


_ K TRNNUM 





@ Key in *ALL to indicate data will be entered into all fields (which is done in this 
example}. 


You can choose the fields into which you will be entering data by placing an X 
next to those fields. 
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The next prompt is for entry format definition: 





ENTRY FORMAT DEFINITION PROMPT 


For record format name MLGTRNRi® ter: 
Entry format identifier: 1 
Entry format description: et 11 

Display one field per line: ¥NO 
Display multiple records: ¥NO 
Redisplay changes: *NO 

Chain to entry format ID: 


List Transaction 





© Key in T (for transaction). 


The default entry format description shown on the prompt was taken from the 
DDS for record format MLGTRNR. 


The following basic field definition prompt lists the fields selected on the field Jd 
review prompt and allows you to enter specifications for each field: 


BASIC FIELD DEFINITION PROMPT FOR RECORD MLGTRNR 


Define format ID T - Mailing List Transaction 
FIELD NAME ORDER INPUT DISPLAY VERIFY 
BATNUM 1.0 
TRNTYP 2.0 
XACTNM 3.0 
XACTTP 
XNAME 
XADDR 
XCITY 
XSTATE 


MDEF XVAL 
a, iM 


XZIP 
TRNNUM 


IX 1X IX IX Dt D< 1D 1K Dt DK 
IX IX D€ DX 1D I< 1K BD 1K 1D 





© Key in X so that extended definitions can be specified for these fields. > 


For each field, Xs automatically appear in the INPUT and DISPLAY columns. In 
this example, the Xs should remain: however, if you need to remove an X in 
another application, enter a blank over that X. 


The ORDER column defaults to the sequence of the record format. This is the 
order in which the fields will be displayed. The order can be changed, but the 
default order is used in this approach. 


You next receive the extended field definition prompt for each field that had an 


X under the XDEF column. The extended field definition prompt for BATNUM 
is displayed first with the default entries: 


EXTENDED FIELD DEFINITION PROMPT FOR FIELD BATNUM 


Enter the following numeric field attributes: 
Label: @ Batch 


Default spacing: If *NO; enter number of spaces: | 
Newline: Label location: * ABOVE 
Edit code: Accumulate field changes: ¥#NO 
Initial value: 

Autodup: Increment: 

Field exit required: 





A) This information was entered as part of the DDS COLHDG keyword for this field 
in record format MLGTRNR. 


© Key in *YES (*NO is the default) because the batch number for each record needs 
to be automatically duplicated in this example. 
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The extended field definition prompt for TRNNUM is displayed next: 





EXTENDED FIELD DEFINITION PROMPT FOR FIELD TRNNUM 


Enter the following numeric: fieldwttributes: 
Label : A) Transaction 
Number a . 


Default spacing: #Y If #NO, enter number of spaces: 
Newl ine; #NO Label location: 

Edit code: Accumulate field changes: 
Initial value: 

Autodup: NO Increment: 

Field exit required: *YE 





A] This information was entered as part of the DDS COLHDG keyword for this field 
in record format MLGTRNR. 


& Key in 10 because the transaction number (TRNNUM) for each record needs to be 
automatically incremented in this example. This means that TRNNUM will equal 


10 for the first record, 20 for the second record, and so on. 








TRNNUM can be used as a key field to access existing transactions for 
modification or display; however, this use of a DFU program is not discussed 
in this publication. DFU requires any file it uses to have keyed access paths. 


The entry format definition prompt is displayed again so that you can define 


another format: 


ENTRY FORMAT DEFINITION PROMPT 


For record format name MLGTRNR 
Entry format identifier: 
Entry format description: 
Display one field per line: 
Display multiple records: 
Redisplay changes: 

Chain to entry format ID: 





enter: 


Mailing List Transaction 
*#NO 
*#NO 
¥NO 


Because no additional entry format needs to be defined, press the Enter key 
(without making any entries) to continue the prompting sequence. 
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The last prompt used to create the DFU definition is the audit control prompt: 


AUDIT CONTROL PROMPT 


Enter the following: 
Add/delete records allowed: 
Change records allowed: 

Key changes allowed: 
Print additions: 
Print changes: 
Print deletions: 
Date error option 
(“NOTIFY *DISPLAY *CHANGE ): 





This display allows you to specify the following: 


e Whether records in the file can be added/deleted, be changed, or have their 
key fields changed. 


e Whether a printed report will contain additions, changes, and/or deletions. 


e Whether the display that notifies you of errors during the creation process 
(if any errors occur) allows you to: 
— Only bypass or delete the record in error (*NOTIFY). 
— Also display or print information about the record in error (*DISPLAY). 
~— Display and bypass or delete the record in error, or correct the error 
before the creation process continues (*CHANGE). 


The defaults that automatically appear are used, and no additional information 
needs to be entered. 


Cc 


The definition of the MLG110U application is now complete, and you receive 
the exit application definition menu. You select option 5 to indicate that you 
want to create the application: 


EXIT APPLICATION DEFINITION MENU 


Select one of the following: 
1. Restart definition 
.2. Modi fy definition 
3. Delete definition 
4. Save definition 
5. Create application 


Option: 


Display fat 'T ' red fmt MLGTRNR too large for console. 





The definition that was entered becomes a source member in the source file 
QUDSSRC. The intermediate output of DFU is a utility definition specification 
(UDS), which is a group of source statements from which |DU applications are 
created. The statements are stored in the source file QUDSSRC and allow you 
to modify an existing DFU application. The name of the source member is 
MLG110U, which becomes the name of the DFU application when the 
application is created. 
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Because you selected option 5 on the exit application definition menu, you 
receive an application creation prompt: 


APPLICATION CREATION PROMPT 


Enter the following: 
Application name: MLG110U 
Library name; MLGLIBDEV 
Adopt owner's user profile: (1-Normal 2-None 3-All1) 
Public authority: (Y-Yes N-No) 
Source listing: (Y-Yes N-No) 


Dump internal data areas: (Y-Yes N-No) 
Generated code listing: (Y-Yes N-No) 


Display fmt 'T ' red fmt MLGTRNR too large for console. 





To create the MLG110U application, you need only accept the defaults shown 
and press the Enter key. When the create function is complete, the user library 
MLGLIBDEV contains a DFU application named MLG110U as well as a DFU 
display file named MLG110U. 


As soon as the application has been created, you receive a menu for executing 
it. In this approach, you are creating the application for later use by work 
station users and do not want to enter transactions; therefore, you press the 
CF1 key to exit DFU. The DFU menu is shown again. When you press the 
CF1 key, the programmer menu reappears. 











Executing the DFU Application 


Once the DFU application MLG110U has been created, work station users can 
enter transactions into the transaction file by executing the application. You 
can execute a DFU application by: 


e« Selecting option 1 on the programmer menu, aS you did to create the 
MLG110U application, and then selecting option 2 on the DFU menu when 
it is displayed. 


e« Enter the Change Data (CHGDTA) command. 


There are several ways that the CHGDTA command might be entered by the 
work station user. A method that uses user-created menus is described in 
Appendix B. 


Assume at this point that you enter the CHGDTA command through the 
programmer menu to test the DFU application MLG110U. The command is 
entered on the programmer menu as follows: 


PROGRAMMER MENU 
Select one of the following: 
" Design/execute DFU app (app), ;loptions) 
Design/execute query app (app), ,loptions) 
Create object object name; type, pgm for CMD, (text) 
Call program program name 
Execute command command 
- Submit job (job name), (command) 
Display submitted jobs 
Edit source (srembr), (type), (text) 
. Design display format (srcmbr ) 
Sign of f (*NOLIST *LIST) 


* 


owon ey tf wn = 


0 


Types: BSCF, CBL», CL, CLP, CMD, CMNF, DSPF, LF,» PF» PRIFs RPG, TXT 


Option: 5 Parm: Type: Parm 2: 
Command: chadta app(mlqll0u) 
Text: Log requests: *YES 


Sre file: Src lib: MLGLIBDEV Obj lib: MLGLIBDEV Jobd: MLGLIBDEV 
CF3-Command entry CF4~-Prompt (3&5 only) CF6-DSPMSG 
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When MLG110U is executed, the following display appears if no records exist 
in the file: 


T_ Mailing List Transaction MLG110U 


Batch Trans Account Acct Name Address 
> Number Type Nupber Type) 


8 ] City | State Transaction 


‘Number 





© The Auto Dup indicator is blank initially. An A is displayed when the Auto Dup 
key is pressed. 


& You can key in transaction records on the blank lines. 


The auto increment indicator must be on before a record is entered. The 
indicator is set on by pressing the Auto Increment key (CF7). The first record 
iS assigned the transaction number of 10. Assign a unique batch number to 
the first record and, after this record is entered, press the Auto Dup key (CF6). 
Because Autodup was specified in the extended field definition for BATNUM, 
the batch number is automatically duplicated for each subsequent record until 
the Auto Dup key is pressed again. 


A unique transaction number is automatically assigned to each transaction 
record. Because an increment of 10 was specified in the extended field 
definition for TRNNUM, transaction numbers for consecutive records are 
consecutive and in increments of 10. 


lf records exist in the file when MLG110U is executed, a display that allows 
you to enter the transaction number of the transaction record you want to 
change appears. If you want to add a transaction record, press CF9 and the 
display (previously shown) that allows you to enter new transaction records 
appears. 


When all of your transactions are entered, press the Exit Application key (CF1). 


The exit application prompt is displayed as follows with a summary of the 
types of records you entered: 


EXIT APPLICATION PROMPT 


Enter the following: 
Exit application: Y  tY¥-Yes N-No} 


DELETED CHANGED VERIFIED 
0 0 0 





To end the job, press the Enter key. The programmer menu is then displayed. 
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APPLYING TRANSACTIONS TO THE MASTER FILE 


Transactions are applied in a batch manner to the master file by using an RPG 
II| maintenance program. In Chapter 4, the maintenance program, MLG310, 
used program-described data. In this approach, the RPG III maintenance 
program, MLG311, will be using externally described data in the data base file, 
MLGTRNL. MLG311 applies the transactions from MLGTRNL to the master 
mailing list file, MLGMSTL. 
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Creating the Maintenance Program 
The steps to create MLG311 are outlined here: 


« Invoke SEU from the programmer menu by Selecting option 8 and specifying 
MLG311 for srcmbr, RPG for type, and MLGLIBDEV for the source library 
(see the discussion of the Source Entry Utility in Chapter 5). 


« Enter the source statements. 


The source for MLG311 is placed in QRPGSRC using SEU, as shown in 

Figure 7-1. The source ts the same as that for MLG310 except for the 

following: 

— Substitute the RPG Control! and File Description Specifications in Figure 
7-2 for those in Figure 4-3. 

— Substitute the RPG Input Specifications in Figure 7-3 for those in Figure 
4-5. 


« Select option 3 on the programmer menu to create the object (RPG II\ 
maintence program) named MLG311. 
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Figure 7-1. The MLG311 Maintenance Program is a Member of QRPGSRC 
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RPG CONTROL AND FILE DESCRIPTION SPECIFICATIONS GX21-9092. 


M Printed in U.S.A. 
= Internanongt Butinent Machines Composation 















t 2 75 76 77 78 79 80 


Program 
rom [192 teennvemon Mb 1@/3]2] 2 





Card Etectro Number 





5: or am Keying 


instruction 















Programmer 





Control Specifications 
























































8 5 
: Fs 
5 ae E 
ani nm + rv a 
€ ol oe 6/6 a3 
2 8 _ Number |= al =| =| as 5s a E|= Refer to the specific System RPG 
2 Size to o 3 € of Print 1% Reverved < 3 3 alo 4 a a i : Reterence manual for actual entries, 
a| Execute eg #/& Positions |Y 2 215 5 ae 3 Q c z x}? J|2 
Line 6 Bes sly s z| F/B E) S| 8/2/E) 8) 5 é/ 3/2/38 3/3 
S wm 5 ue | wa = 2 5 f (X16 a|- $ S| C] e 3 ol E o E 2 
= Bl § z/ 2/5 5 ge] @ sitls|s 8 31 1E 12) 5[e| 3 3/5 
3 fa) fe 3 rat oVe Zz =| & Aj =| S]u a Z\|cle ulejael] gm 
tt[t2 13 14 /16718 87/18) 18] 20) 21 273 «24 25 /126[27 28 79 30 313.3233 M 35 36/47/36 39) 40] 41 50| $1] 52 | 55/56/57 58 59 60 Gt 62 63 64 65 66 67 68 69 70 Tr 77:73 «74 













File Addition/Unordered 






Extent Exit Number of Tracks 










Length of Key Fiald or 







































Fite Designation 
of Record Address Field z for DAM tor Cylinder Overllow 
= Name of 
Symbolic > ee Eh Number of Extents 
Filaname Typa of Fite Device Device 3 a xi Tape 
File Format ™  Orgenittion or Rewind 
— 5 Additional Ares 4 Storage Index Fie 
a 
F3 Block Condition 
> Lengih ] uc ' 
~~ . . 
a 3 1 
External Aecord Name = 
19 20 2) 22 23 24 25 26 27 28 29 30 31 37:39 44 '39| 40 at 47 43 44 45 46 6? 70171 72|73 74 








SIG leas 
TAN M 


Tis [plelsle 
tes elles 
a 
fel 
E 


es ae ae ee ee 























alm) EH 





RPG INPUT SPECIFICATIONS GX21-9004-4 UM/050° 


Printed in U.S.A, 
75 76 77 78 79 90 


roe | 2 of Z ee es M elg {s/t ia) 


IEM 
Interralioamd Burnes Machines Corporation 


eS come em] TT _] oes eeere nino 
[rayon done i ton Fey PT PE 


External Field Name 




















































































5 . Field 
= Field Location indicators 
uw 
Fitename 3 Record Identification Codes = 5 
= a aS 
or oy = ia 5 a 
" Record Name Wen > 2 RPG ~ |3s| « 
a Sissi ° = ; sits 
- z|>/< | 3 Field Name z ical & 
=-[= les . 
to = & 
8 — Bls|e | Position [2/9] 8) Position a) 8] 2)3 £ 2 |é <| x 
= =] a Al ao = 2 
Structure 5 & 2 o olG x Length & 6136) «4 
Neme 
1 4 5/@]7 @ 9 10151 82 17/18/19 20/21 22 23 24/25)26 3a|39] 40] 41) 42/43] 44 45 46 47/48 49 Su 91/52/53 54 55 56 57 58/159 aolet 62/6) 64/65 66/67 Gales 70171 72 73 74 





oT peel tral PLL 
ela SUI ETE TOES AIEEE ET TS ie ETSI PSSST Te eT eT TPS ei] 





Figure 7-3. Input Specifications for MLG311 Maintenance Program 
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Executing the Maintenance Program 
When MLG311 Is executed: 
e The transactions from MLGTRNL are applied to the master file MLGMSTL. 
« A report that lists the changes made to the master file MLGMSTL is printed. 


A work station user executes the MLG311 maintenance program by calling it. 


For example, you could call the program by using option 4 on the programmer 
menu: 


PROGRAMMER MENU 
Select one of the following: 

Design/execute DFU app (app), »(options) 
Design/execute query app (app), »>{options ) 

. Create object object name, type, pgm for CMD, (text) 
Call program program name 
Execute command command 

. Submit job (job name), (command) 
Display submitted jobs 
Edit source (srcmbr), (type), (text) 
Design display format {srembr ) 

90. Sign off (¥NOLIST ¥*LIST) 


Types: BSCF, CBL, CL», CLP, CMD, CMNF, DSPF, LF» PF» PRTF, RPG, TXT 


Option: 4 Parm: HLG311 Type: Parm 2: 
Command: 


Text: Log requests: *YES 
Sre file: Sre lib: MLGLIBDEV. Obj lib: MLGLIBDEV Jobd: MLGLIBDEV 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPHSG 





Option 4 calls a program. 


The name of the program to be called is specified here. 


0 0 6 


lf a library name is specified here, the system searches only the specified library 
for the program instead of searching the libraries in the library list. 
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The disadvantage of using this method is that you cannot use the work station 
again until the program is completed. However, you can go on to other tasks 
at your work station if you include the CALL command in a batch job that you 
submit from your work station. You can submit a batch job from the 
programmer menu to call the MLG311 program: 





PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app), »(options) 
2. Design/execute query app (Capp), ;(options) 


3. Create object object name, type, pqm for CMD, (text) 
&. Call program program name 
Os: Execute command command 
6. Submit job (job name), (command) 
. DIispley submitted jobs 
.» Edit source (srcmbr), (type), (text) 
- Design display format (srcmbr ) 
. Sign of f (*NOLIST *LIST) 


Types; BSCF, CBL, CL, CLP, CMD, CMNF, OSPF, LF, PF» PRTF; RPG: TXT 


Option: 6 Parm: MLG3]1 Type: Parm 2: 
Commands ceil mlq31}]_ 
Text: LC Log requests: #YES 


Sre file: Src lib: MLGLIBDEV Obj lib: MLGLIBDEV Jobd: MLGLIBDEV'@® 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6é-DSPMSG 





Option 6 submits the job for batch processing. The job is placed on the QBATCH 
job queue. 





You specify the job name here. If you leave this field blank, QBATCH is used for 
the job name. 


This CALL command is submitted as part of the job and is executed when the job 
is selected from the job queue. 


The submitted job uses the job description MLGLIBDEV as specified here. 
Because you did not specify a job queue when you created the MLGLIBDEV job 


description (Chapter 6), the default job queue, QBATCH, is used. 


Oo 
Programmer 


e 
call mlg311 
e 
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When the job MLG311 is selected from the QBATCH job queue, the CALL 
command is executed and the MLG311 program begins applying the 
transactions to the master file. After MLG311 has updated the master file, a 
listing of the updates is printed by the spooling writer. 


The data in the transaction file can be removed when it is no jonger needed. 
MLGTRNNP is cleared by entering the Clear Physical File Member (CLRPFM) 
command on the programmer menu as follows: 


PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app), » (options) 
2. Design/execute query app lapp), »(options) 
3. Create object object name, types pgm for CMD, (text) 
4. Call program program name 
5. Execute command command 
Submit job (job name), (command) 
7. Display submitted jobs 
Edit source (srembr), (type), (text) 
Design display format (srembr ) 
. Sign off (#NOLIST *LIST) 


Types: BSCF, CBL, CL, CLP, CMD, CHNF, DSPF, LF, PF; PRTF,; RPG», TXT 


Option: 5 Parm: ___s« Parm 2: 
Command: clrpfm fi Tetalate 


Text: Log requests: *YES 
Src file: Src lib: MLGLIBOEV. Obj lib: MLGLIBDEV Jobd: MLGLIBDEV 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPNSG 





After MLGTRNNP is cleared, it is ready to have a new group of transactions 
entered into it. 
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RECOVERY CONSIDERATIONS 





If incorrect data has been entered for a transaction, the entire transaction 
should be reentered with the correct data. 


If there is a system failure while the maintenance program MLG311 is 
executing, the current batch of transactions should be reprocessed in most 
situations. The maintenance program rejects invalid transactions, such as a 
request to add a record with an account number that already exist in the 
master file. If a system failure occurs when you are not executing the 
maintenance program, no recovery is normally needed. 


If there is a system failure while the transactions are being entered through the 
DFU application MLG110U, the transaction file (MLGTRNP) will normally be 
readable after another initial microprogram load (IMPL). DFU allows the work 
station user to determine the last transaction in the file and then continue from 
that point. 


If neither the DFU application nor the maintenance program is executing when 
a system failure occurs, normally there are no recovery considerations for the 
application. 


To allow for recovery from damaged objects (assuming you are maintaining the 
master file with one or more batches per day), the master file could be saved 
every 2 to 3 days. If the damaged master file is not usable, the backup can be 
restored and the saved transactions can be reprocessed. You should keep both 
the current backup and at least one earlier level of backup. The data in the 
transaction file MLGTRNP must be considered for backup prior to entering J 
another batch of transactions. Two approaches could be: 





« Save each batch of transactions after it is processed. 


« Copy the processed transactions to a common file for all of the transaction 
batches and save that file at the end of the day. This approach is probably 
more desirable because it minimizes what the system operator must do 
during the day; however, there is an exposure that the transactions must be 
rekeyed if the entire system becomes unusable. 


Neither of these approaches is described in this publication, but it is assumed 
that one of them has been implemented. 
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PROGRAMMING CONSIDERATIONS 


Part of the approach in this chapter described submitting the batch 
maintenance job, backing up the transactions, and clearing the transaction file. 
The work station user could have initiated these tasks by submitting a CL 
program through a user-written menu that would execute the program as a 
batch job. User-written menus are discussed in Chapter 8, and submitting jobs 
from a menu is described in Appendix B. 


Providing a way for the work station user to submit a CL program that 
executes a series of standard commands is usually a good technique because: 


« The work station user knows when the batch is complete. 
« The system operator does not have to be involved (assuming that the 


backup is done by copying the transactions to a common file during the 
day). 
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Chapter 8. Interactive Input and Interactive Maintenance 


OVERVIEW 


In Chapter 7, transactions were entered interactively into a transaction file from 
a work station, and this batch of transactions was then applied to the master 
file by an RPG IIl maintenance program. The approach in this chapter allows 
work station users to interactively update the master file itself. 


A DFU application, MLG315U, provides the displays on which the work station 
users enter transaction records. The application applies the entered records to 
the physical master file)s MLGMSTP, through the access path provided by the 
logical master file, MLGMSTL. 


Each work station user who invokes the MLG315U application sees the same 
set of transaction-entry displays. However, different work station users could 
invoke the application in different ways. Three ways of invoking the application 
are described in this chapter (see illustration on the next page): 


@ = The work station user invokes MLG315U directly from his basic working 
display, such as by entering the Change Data (CHGDTA) command on 
the programmer menu. 


@ The work station user calls a CL program, MLG315C, from the 
IBM-supplied program call menu, and the MLG315C program invokes 
MLG315U. 


rc ] The work station user signs on with a special user profile that defines the 
CL program, MLGOOSC, as the initial program. The MLGOOSC program 
establishes the proper application environment by replacing the library list 
and then calls a CL program, MLGO35C, which provides an 
application-oriented menu. When the work station user selects an option 
on the specialized menu, the MLG315U application is invoked. 
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This chapter also discusses two IDU functions for making inquiries into the 
master file: 
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« Using the DFU application, MLG230U, to make inquiries by zip code into 
the master file, MLGMSTP, through a second access path defined by the 
logical file, MLGMSTL2. 
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* Using the Query application, MLG910Q, to select and print records from the 
master file, MLGMSTP. 
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DFU APPLICATION FOR INTERACTIVE MAINTENANCE 


The approach in Chapter 7 allowed work station users to interactively enter 
transaction records, but the actual maintenance of the master file (applying the 
transaction records to the master records) was done by an FPG II| 
maintenance program. In the approach presented in this chapter, changes are 
entered directly into the master file by a DFU application named MLG315U. 




















DFU 
Transaction Application Logical Physical 
MLG315U Master Master 
File File 





This online maintenance has the following advantages: 


« Most businesses that use online maintenance experience fewer clerical 
errors. The individuals making the changes tend to operate in a more 
thorough manner because they can readily see the impact of their work. 


* A change to the master file is effective when it is entered and the changed 
record is available to other programs. 


« The master file tends to be more accurate because an existing record is 
displayed before it is changed or deleted. Consequently, there is better 
validity checking, which can reduce the time required for correcting errors 
such as invalid codes and duplicate account numbers. 


° The individual who knows a change that should be made can make the 


change himself. This approach would bypass the steps of transcribing the 
changes to a source document and then into a machine processable form. 
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Creating the DFU Application 


To create the DFU application MLG315U, select option 1 on the programmer 
menu as follows: 





PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app), ,»Coptions) 
2. Design/execute query app (Clapp), ;»loptions) 
3. Create object object name, type, pgm for CMD, (text) 
4. Call program program name 
5. Execute command command 
6. Submit job (job name), (conmand) 
Display submitted jobs 
Edit source (srembr), (type), (text) 
Design display format (srembr ) 
Sign off (#NOLIST *LIST) 


Types: BSCF, CBL, CL, CLP, CMD, CHNF, OSPF, LF, PFs PRTF, RPG, TXT 


Option: | Parm: MLG3J5U.. Type: Parm 2: 
Commaryd: 


Text: OC#dLCOFG requests: #YES 
Sre file: Src lib: MLGLIBDEY Obj lib: MUGLIBDEY. Jobd: MLGLIBDEV 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPMSG 





You receive a series of DFU displays on which you define the MLG315U 


application. The first display is the DFU menu. Select option 1 to create an 
application: 


DFU MENU 


Select one of the following: 


1. Create or change an application 
2. Execute an application 


3. Manage existing application 


Option: i 


Press HELP for instructions. Press CFl1 to exit. 





The DFU create/change menu appears next: 


DFU CREATE/CHANGE HENU 


Select one of the following and enter values below: 
1. Display information about an application 
2. Create a new application 
3. Change an existing application 
4. Delete an existing application 


bo A) 
Option: 2 
© 


Application name: MLG315U (*-Application selection list) 


Library name: MLGLIBDEV 


HELP-Help CF2-Previous display 





A] Select option 2. 


@ The application name and object library that you specified on the programmer 
menu are shown here. 
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You then receive the DFU create prompt: 


DFU CREATE PROMPT 
Application name: ML6315U Library: MLGLIBDEV 


Enter information 
Description: 
File name: 

Library name: 


HELP-Help CF2-Previous display CF3-File information 





A) Key in the text description of the application. 


(3) Key in the name of the file to be accessed and the library where the file is 
located. 


After completing the create prompt, you receive an application control prompt 
that shows the application name (MLG315U), file name (MLGMSTL), and their 
respective library names as you specified previously: 


APPLICATION CONTROL PROMPT 


Application name: MLG315U Library: MLGLIBDEV 
File name: MLGMSTL Library: MLGLIBDEV 


Place an X next to the display size: “) 
Primary display size: = 24X80 _ 12X80 _ 16X64 
ee Tea: 


Take defaults after field selection: @itv-ves N-No) 


HELP-~Help CF2-Previous display 


A) Key in X if not shown here. 


B ] Do not change this default value; you will be modifying the definitions. 





A file review prompt is: displayed next: 


FILE REVIEW PROMPT FOR FILE MLGMSTL A) 


For each record format to be used, enter R to review the fields, A to select all 
fields, or E to enter the fields later: 
RECORD FMT DESCRIPTION 
A MLGMSTR Mailing List Master 





© This is the file name you specified on the DFU create prompt. 


@ Key in A to specify that you will be entering data into all fields. 


The next prompt is for entry format definition: 


ENTRY FORMAT DEFINITION PROMPT 


For record format name MLGMSTR enter: 
Entry format identifier: M. 
Entry format description: Mailing List Master 
Display one field per line: *NO 
Display multiple records: *NO 
Redisplay changes: *NO 
Chain to entry format ID: 





@ = Key in M (for master file). 
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You then receive the basic field definition prompt, which lists all fields and 
allows you to select specifications for each field: 


BASIC FIELD DEFINITION PROMPT FOR RECORD MLGMSTR 


Define format IDM - Mailing List Master 
FIELD NAME ORDER INPUT DISPLAY VERIFY XDEF XVAL 
ACTNUM : 
ACTTYP 
NAME 
ADDR 
CITY 


o lo 
De >< IX De D< D< Dx 


o~ 
i | 
Pert tt bpp t 1th 


Mee 


—e 
— 71.9 
—_—_ 
= a 


2. 
biudd 1 Be 1X 19¢ 12¢ I< D< 1x 


— i" 
tirade 
i, 
La 


& Key in X so that validity checking can be specified for these fields. 


@ Key a blank into each position (the MLGLK1 field is not used in this approach). 


The Xs that automatically appear in the INPUT and DISPLAY columns should 
remain. 








The validity check prompt for ACTTYP is displayed first: 


VALIDITY CHECK PROMPT FOR FIELD ACTTYP 


Select validity checks by inserting X; or cancel with blanks 
_ Mandatory entry _ Mandatory fill 
_ MOD10 check _ M0011 check 
geMame check . Ablow blanks 
X Relational operator: *LS List of values: 


@ Key inx. 


() Key in *LS to specify there will be a list of values. 


© Key in the valid values for which this field will be checked. 


The validity check prompt for STATE is displayed next: 


VALIDITY CHECK PROMPT FOR FIELD STATE 


Select validity checks by inserting X; or cancel with blanks 
_ Mandatory entry X Mandatory fill 
_ MOD10 check A _ MOD11 check 
_ Name check — Allow blanks 
_ Relational operator: __ —s- List of values: 


& Key in X to specify that this field must contain an entry in each position. 
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DFU can check a list of up to 20 values. Consequently, all of the valid state 
codes cannot be checked. The validity checking for the STATE field differs 
from the previous example for the ACTTYP field where an RPG array was used 
to validate the field. 


The validity check prompt for ZIP is displayed next: 


VALIDITY CHECK PROMPT FOR FIELD ZIP 


Select validity checks mserting X, or cancel with blanks 
_ Mandatory entry Oh sbersstory fill 
_ Modo check —_ Ll check 
_ Name check — Allow blanks 


_ Relational operator: List of values: 





@ Key in X to specify that this field must contain an entry in each position. 


The entry format definition prompt is displayed again: 


ENTRY FORMAT DEFINITION PROMPT 


For record format name MLGMSTR enter: 
Entry format identifier: a 
Entry format description: aili List Master 
Display one field per line: *NO 
Display multiple records: *NO 
Redisplay changes: #NO 
Chain to entry format ID: 





Because no additional formatting needs to be defined, press the Enter key 
(without making any entries) to continue the prompting sequence. 











The last prompt used to create the DFU definition is the audit control prompt: 


AUDIT CONTROL PROMPT 


Enter the following: 
Add/delete records allowed: 
Change records allowed: 

Key changes allowed: 
Print additions: 
Print changes: 
Print deletions: 
Data error option 
(*#NOTIFY *DISPLAY *CHANGE ): 





a) Key in *YES (*NO is the default) to receive a printed listing. 


The exit application definition menu is displayed next. Select option 5 to 
indicate that you want to create the application. 


EXIT APPLICATION DEFINITION MENU 


Select one of the following: 
1. Restart definition 
2. Modify definition 
3. Delete definition 
4. Save definition 
5. Create application 


Option: 


Display fmt 'M ' rcd fmt MLGMSTR too large for console. 
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Because you selected option 5 on the exit application definition menu, you 
receive the application creation prompt: 


APPLICATION CREATION PROMPT 


Enter the following: 
Application name: MLG3}5U 
Library name: MLGLIBOEV 
Adopt owner's user profila: (1-Normal 2-None 3-All) 
Public authority: (Y-Yes N-No) 
Source listing: (Y-Yes N-No) 


Dump internal data areas: (Y-Yes N-No) 
Generated code listing: (Y-Yes N-No) 


Display fmt 'M ' rod fmt MLGNSTR too large for console. 





To create the MLG315U application that you have just defined, you need only 
accept the defaults as shown and press the Enter key. When the application 
creation is complete, the MLGLIBDEV library contains a DFU application named 
MLG315U as well as a DFU display file named MLG315U. 


You next receive a menu for executing the application. In this approach, you 
do not want to use the application at this point, so you press the CF1 key to 
exit DFU. You receive the DFU menu. When you press the CF1 key again, 
the programmer menu reappears. 





Executing the DFU Application 


By executing the DFU application MLG315U, work station users can enter 
transactions to update MLGMSTP using the access path defined by 
MLGMSTL. The MLG315U application can be executed by: 


e Selecting option 1 on the programmer menu, as you did to create the 
application, and then selecting option 2 on the DFU menu when it is 
displayed. 


« Entering the Change Data (CHGDTA) command. 


In this approach, the CHGDTA command is used, because its direct result is 
the first display of the application without any intermediate displays (the DFU 
menu). 


There are several ways that this command could be entered by the work 
station user. A menu approach is discussed later in this chapter and in 
Appendix B. 


Assume at this point that the command is entered by the programmer through 
the programmer menu to test the DFU application MLG315U. The command is 
entered on the programmer menu as follows: 


PROGRAMMER MENU 
Select one of the following: 
. Design/execute DFU app (app), » (options) 
. Design/execute query app (app); ;(options) 
. Create object object name, type» pgm for CMD, (text) 
Call program program name 
Execute command command 
Submit job (job name), (command) 
Display submitted jobs 
Edit source (srembr), (type), (text) 
Design display format (srembr ) 
Sign off (¥NOLIST *#LIST) 


Ou e@waytrw SUN & 


os] 


Types: B6BSCF, CBL, CL> CLP, CMD, CMNF, DSPF, LF, PF, PRTF, RPG» TXT 


Command: chadta app(mlq315u) 


Text: Log requests: *YES 
Sre file: _ _——s——s Gre Lib: MLGLIBDEV Obj lib: MLGLIBDEV Jobd: MLGLIBDEV 
CF3-Command entry CF4-Prompt (3 & 5 only) $CF6-DSPMSG 


' Option: 5. Perm: Type: Parm 2: 
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When MLG315U is executed, the following display will be in add mode if no 
records exist in the file. If records do exist, the display will be in change mode 
as follows: 


M_ Mailing List Master MLG315U 


Account 
Number 





This display allows you to enter the account number of the record you wish to 
change. After you have entered an account number, the record with that 
account number is displayed as follows: 


M_ Mailing List Master MLG315U 


Account Acct Name Address City 
Number Type 


12345 1 =W_A SMITH 0 MAIN LOS ANGELES 


State Zip 
Code 


CA 20045 


You can change any of the fields on this display by keying in the changes and 
pressing the Enter key. The CHANGE prompt will be displayed again. Also, 
the command keys can be used to perform various functions at this time. For 
example, if you press the Add key (CF9), the following is displayed and you 
can add records to the master file: 


M_ Mailing List Master MLG315U 


Account Acct Name Address 
Number Type 


State 





When all of your maintenance has been performed, press the Exit Application 
key (CF1). The following exit application prompt is displayed: 


EXIT APPLICATION PROMPT 


Enter the following: 
Exit application: Y (Y-Yes N-No) 


DELETED CHANGED VERIFIED 
0 1 0 





To end the application, use the default (Y) as shown. 
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A listing of the changes, additions, and deletions made to the master file is 
written to a spooled output file and placed on the QPRINT output queue for 
printing (this was specified in the audit control prompt). A sample printed 


listing is shown below. ; 


STI14UT1 RO2M00 810302 AUDIT LOG O9/21/4l 14:41:57 PAGE l 

Application: MLG3ISUS*MLGOLISOEV 

File: MLOMSTLaMLGOLIA@0cV Member: MLGPSTL 
ACTION RECORD Account Acct Name A i 

ddress j 
eee pas City State a 
aos CHG MLGOMSTR 12345 l WH A S¥PITH & 500 MAIN ST ™ LOS ANGELES CA ee ec0n8 
ER CHG SMLGMSTR 12345 l WwW A SFITH 320 PACIFIC AVE SAN JOSE CA 95112 


USING THE PROGRAM CALL MENU 
Any work station user can be given authorization to any command on the 
system, be limited to specific commands, or be given only application-oriented 
functions. Therefore, you must consider: 
« What the work station user should be allowed to do. 


e« How the work station user's task can be made easier. 


There are many alternatives to signing on and presenting the first display for 
the work station users. These alternatives may require changes such as: 


« Modifying the |BM-supplied password 


« Creating unique user profiles 





e« Creating application-oriented menus (discussed later in this chapter and in 
Appendix B) 


In the previous approach, transactions were entered as a result of the 
programmer using the CHGDTA command to test the DFU application 
MLG315U. To limit the direct exposure of the work station user to the control 
language commands, this approach assumes the |BM-supplied user profile 
QUSER and the |BM-supplied program call menu (QCALLMENU) are used. 
This menu ts displayed when the work station user signs on with the password 
USER: 


PROGRAM CALL MENU 
Select one of the following: 
1. Call program (identify below) 
2. Display messages 
3. Send message to system operator 
90. Sign off work station (#NOLIST *LIST) 


Option: __ Program name: 
Parameters or message: 





The program call menu allows the work station user to call a program that has 
been created by the programmer. The other options let the user: 


« Display any messages sent to his work station 
e Send a message to the system operator 
¢ Sign off 


Although the program call menu allows the work station user to call a program, 
it does not allow the execution of most commands. To directly execute the 
DFU application MLG315U described earlier in this chapter, the CHGDTA 
command must be used. You can create a CL program to execute one or more 
commands for the work station user. For this approach to signing on and 
calling the application from the program call menu, the programmer develops a 
CL program named MLG315C. This CL program allows the work station user 
to execute the commands necessary for the DFU application without knowing 
the specific commands. 


CL Program: (etka 4 
MLG315C a 
CALL SETLIBL he ee 
CHGDTA MLG315U /MLG315U 





Physical 
Master 
File 
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Creating the Control Language Program 


Because SEU will be used to enter the source for the CL program, called 
MLG315C, select option 8 on the programmer menu as follows: 





PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app), »Coptions ) 
Design/execute query app (app), ,loptions) 
Create object object name, type, pgm for CMD; (text) 
Call program program name 
Execute command command 
Submit job (job name); (command) 
Display submitted jobs 
Edit source (srombr), (type), (text) 
Design display format (srembr ) 
Sign off (*#NOLIST *LIST) 


Types: BSCF, CBL, CL; CLP; CMD, CMNF, DSPF, LF, PF, PRTFs RPGs TXT 


Option 
Comman -™ 
HLG315U ilog requests: *YES 


— 72 aeration ISUEVNUNSERIDIERUGENEDCV Jobd: MLGLIBDEV 
SFonuand ent CF6-DSPMSG 


a — 
.. — 2 Ss 





When you receive the SEU display, enter the following source on the display: 


SEU US H:1 Mbr :MLG315C Scan: 
PMT MR: Sad. wore WN ce dade Cone Rae BAe: hae OW! was: ba Bone 
HH**#BEGINNING OF DATAM#HI0 
0001.00 PGM /* MLG3I5C MAILING LIST MAINTENANCE #*/ 
Qeewrwercate SETLIBL.MLGLIBDEV 
OOOEEOO= CHGDTA APP(MLG31L5U) 
0004.00 ENDPGM 
HHH HREND OF DA TA 36 96 9696 96 96 





& The CALL command is needed to replace the library list for the mailing list 
application. 


8 This command is the same as the CHGDTA command previously used to test this 
application (see Executing the DFU Application in this chapter). 


After exiting SEU, you create the CL program from the programmer menu as 
follows: 


PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app), » (options) 
2. Design/execute query app (app); »(options) 
3. Create object object name, type, pgm for CMD, (text) 
4. Call program program name 
5. Execute command command 
6. Submit job (job name), (command) 
7. Display submitted jobs 
8. Edit source (srembr), (type), (text) 
9. Design display format (srembr ) 
90. Sign off (¥NOLIST *LIST) 


Types: 8SCF, CBL, CL, CLP; CMD, CMNF, DSPF, LF» PF, PRTF,» RPGs TXT 


Option: 3. Parm: MLG315C Type: CLP_ Perm 2: 
Command: 


Text: CL Program for Mailing List Clerk to Use MLG315U_ Log requests: #YES 
Src file: Src lib: MLGLIBDEV Obj lib: MLGLIBDEV.  Jobd: MLGLIBDEV 


CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPMSG 





Using the Control Language Program 


After the CL program is created, the work station user can call the program 
from the program call menu as follows: 


PROGRAM CALL MENU 
Select one of the following: 
1. Call program Cidentify below) 
2. Display messages 
3. Send message to system operator 
90. Sign off work station (*NOLIST #LIST) 


Option: {0 Program name: MLG315C .MLGLIBDEV 8) 


Rarameters or message: 





A) Key in 1 to call a program. 


GH) Key in the qualified name (program name and library name). 


After the work station user has entered the indicated information on this 
display, the DFU application MLG315U begins. The displays that follow would 
be the same as those previously described in this chapter under Executing the 
DFU Application. 
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Programming Considerations 


In this approach, the work station user had to enter a qualified name (both the J 
program name and the library name) for the program to be called. When the 

work station user signed on, a system wide default library list was used. This 

list would normally not include the library MLGLIBDEV. Calling the program 

would have been easier for the work station user if the CL program MLG315C 

had been placed in the general purpose library (QGPL). The work station user 

would have only been required to enter the program name. Another alternative 

for calling this program is discussed next in this chapter. 


USING A USER PROFILE AND AN APPLICATION-ORIENTED MENU 


In the previous section, work station users used the program cali menu to 
simplify their data entry work. In this section, a different approach to 
simplifying the work station user's job is discussed: a user profile is created 
such that an application-oriented menu appears after the work station user 
signs on. This type of menu not only simplifies but helps control what the 
work station user can do. For example, you may want to restrict which work 
station users can maintain the master file or what applications can be used by 


a specific user. 
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Creating the User Profile 


There are several ways to allow the work station user to receive a specific 
menu after he signs on. This section discusses how to create a user profile to 
do this. 


Only the security officer can create or change a user profile. The security 
officer may be the DP manager, the programmer, or another person Signing on 
with the security officer password. When you sign on with the security officer 
profile, you receive the command entry display. 


To create a user profile for all work station users that will be working with 
mailing lists, enter the CRTUSRPRF command on the command entry display 
as follows: 


COMMAND ENTRY DISPLAY 


2: crtusrprf usrprf(mlgqistcirk) password(mlglist) inlpqm(mlq005c.mlqlibdev) 
text('mailing List clerk’ } 


CF3 - Duplicate CF4 - Prompt CF7 - Low level messages 





The work station user can now sign on with the password MLGLST. The name 
of his user profile is MLGLSTCLRK, and the user profile calls the CL program 
MLGOOSC in the library MLGLIBDEV every time the work station user signs on. 
The program displays the mailing list clerk menu as the first display after the 
password MLGLST is entered. 
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Programming Considerations 
The user profile that was created could be used by one person or by more 
than one person (all could be active at the same time). in many work 


environments it would be desirable to create a unique user profile for each 
user. 


Application-Oriented Menu 


The application-oriented menu for this approach is shown below. 


MAILING LIST CLERK MENU 
Select one of the following: 
1. Maintain mailing list file 
2. Inquire by zip code 
90. Sign off 


Option: 














Three options are shown: 


« If option 1 is selected, the CL program MLGOOSC executes the DFU 
application MLG315U, which allows the work station user to update the 
mailing list master file. 


e If option 2 is selected, the CL program executes the DFU application 
MLG230U, which allows the work station user to display the master file by 
name and zip code. 


e If option 90 is selected, the SIGNOFF command is executed and the. 
sign-on prompt appears. 


Before this menu can be displayed, the application environment must be 
established. This is done by the CL program MLGOOSC. 


The CL program MLGOOSC replaces the library list for the application, then 
calls the program MLGO35C, which displays the application-oriented menu. 
The source for the CL program MLGOOSC would be entered by using SEU 
(select option 8 and specify type CLP on the programmer menu). The CL 
program source follows: 


PGM /*MLGOOSC MAILING LIST INVOCATION FOR MAILING LIST CLERK */ 
CALL SETLIBL.MLGLIBDEV 

CALL MLGO35C 

ENDPGM 


The CL program MLGOOSC is created by selecting option 3 and specifying 
MLGOOSC for source member and CLP for type on the programmer menu. The 
set library list program (SETLIBL) must be called before the CL program 
(MLGO35C) for the mailing list clerk menu is called because the program 
MLGO35C is coded to find a file (MLGO35CD) by using the library list. When 
the program MLGO35C is executed, it displays the mailing list clerk menu. 
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Creating the Menu 


To create the menu for the mailing list clerk, two items must be created in the 
following order: 


1. Display file for menu 

2. CL program for displaying menu 

There are two ways you Can create the menu: 

e Code and create the display file and CL program separately. 


« Use the screen design aid (SDA), which creates the display file and CL 
program for you. 


The procedures for separately creating the display file and the CL program will 
be described first, followed by the procedure for using SDA. 


Creating the Display File MLGO35CD 


The display file must be created first because the CL program MLGO35C uses 
the externally described data. The DDS for the display file MLGO35CD are 
shown in Figure 8-1. 
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Figure 8-1. DDS for MLGO35CD Display File 


8-24 











The DDS define the format of the menu and primarily consist of constants and 
an input field (RESP). The RESP field is checked for valid entries. If an invalid 
value (a value other than one of those listed for VALUES) is entered, the device 
support detects the error and a message is displayed: 


MAILING LIST CLERK MENU 
Select one of the following: 
1. Maintain mailing list file 
2. Inquire by zip code 
90. Sign off 


Option: 3 


Value for field not in values list 





Consequently, you do not need to check for invalid codes in the CL program. 


The first line in the DDS is a comment (designated by * in position 7). The file 
contains one record format, named MENU (designated by R in position 17). 


A text description, TEXT("MAILING LIST CLERK MENU’), is given for the 
format name. Constants that will be displayed are quoted (enclosed in 
apostrophes). The line and position entries (under location) specify where the 
fields will be displayed on the screen. The position entry specifies the first 
(leftmost) position of the field. 


The device displays the title in high intensity because the keyword DSPATR(HI) 
is specified. 


The DDS for the display file MLGO35CD would be entered using SEU by 
selecting option 8 and specifying MLGO35C for source member and DSPF for 
type on the programmer menu. To create the display file, select option 3 and 
specify DSPF for type on the programmer menu. 
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Creating the Control Language Program MLGO35C 


The CL program (MLGO35C) for displaying the mailing list menu defined by the 
MLGO35CD display file is the following: 


PGM /*" MLGO35C MAILING LIST MENU */ 
DCLF MLGO35CD 

BEGIN: SNDRCVF RCDFMT(MENU) 
IF (®RESP *EQ 1) CHGDTA APP(MLG315U) 
IF (&RESP *EQ 2) DSPDTA APP(MLG230U) 
IF (&RESP *EQ 90) SIGNOFF 
GOTO BEGIN 
ENDPGM 


The Declare File (DCLF) command specifies the name of the display file which, 
in this case, is MLGO35CD. The display file fields that are to be passed 
between the display file and the CL program are automatically declared in the 
CL program when it is created. 


The first command executed is the Send Receive File (SGNDRCVF) command. 
This sends the record format MENU to the work station display and waits for a 
response (one of the options on the menu). 


When a response is returned, it is compared with the three valid responses in 
the IF statements. The &RESP field designates a variable that is being used in 
the CL program. This variable is defined in the display file as RESP and is 
automatically declared within the program as &RESP. Variables within CL 
programs always begin with an & symbol. Different commands are executed 
depending on the response. If a DFU application is executed, the Exit 
Application key (CF1) must be pressed before you return to the CL program. 


When you return to the CL program, the value of &RESP is not changed and 
the remaining IF statement(s) test the value of &RESP. These tests are not 
successful and the program branches to the BEGIN label, which displays the 
menu again. 


If the SIGNOFF command is executed, the CL program is terminated. 


The CL program MLGO35C would be entered using SEU by selecting option 8 
and specifying MLGO35C for source member and CLP for type on the 
programmer menu. To create the program, select option 3 and specify CLP for 
type on the programmer menu. 











Using the Screen Design Aid 


The previous two sections showed how you can create a specialized menu by 
separately coding and then creating the display file (MLGO35CD) and the CL 
program (MLGO35C) for the menu. By using the screen design aid (SDA) utility, 
you Can avoid the task of coding the display file and CL program. You define 
the menu on the SDA displays, and SDA then creates the display file and CL 
program for you. 


To request SDA, use option 9 on the programmer menu as follows: 


PROGRAMMER MENU 
Select one of the following: 
Design/execute DFU app (app}, »Coptions) 
. Design/execute query app (app), »(Coptions) 
. Create object object name, type, pgm for CMD, (text) 
Call program program name 
. Execute command command 
. Submit job- (job name), (command) 
. Display submitted jobs 
Edit source (scrmbr)}, (type), (text) 
. Design display format (scrmbr } 
. Sign off (¥NOLIST *LIST) 


oo ON ow WH Pe 


0 


Types: BSCF, CBL» CL, CLP, CMD, CMNF, DSPF, LF, PF, PRTF, RPG, TXT 


Option: 9_ Parm: MLGO35C Type: Parm 2: 
Command: 


Text: Log requests: ¥*YES 
Src file: Sre lib: MLGLIBDEV. Obj lib: MLGLIBODEV Jobd: MLGLIBDEV 
CF3-Command entry CFG-Prompt (3 & 5 only) CF6-OSPMSG 





You receive the first SDA display. To create a menu, select option 2: 


SDA OPTION MENU 
Select one of the following: 

1. Design display record formats 

2. Design a menu 

3. Test an existing display record format 


Option: 2 


Within SDA: 
Press HELP key to display help text for the current display. 
Press CFI key to exit any option and allow saving the changes. 
Press CF2 key to back up to the previous display in a series. 
Press ENTER/REC ADV to advance to the next display. 
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Because you indicated you want to design a menu, you next receive the initial 
menu definition display. You can accept the values already shown on this 
display, or you can change them. Use this display to specify the title of the 
menu. 





SDA INITIAL MENU DEFINITION 


Menu/nember : ‘MLGOSSC. 6 
(blank for MEMBER LIST display) 


CL source file: GCLSRC 
Library: *LIBL 


Allow this menu on tha following display sizes: 
CY N) 
Large display (24X80): Y 
Small display (12X80): 
Console (16X64): 


Number of columns for the menu (lor 2): } 


Menu title: MAILING LIST CLERK MENU Q 





© This is the name you entered on the programmer menu. 


© Specify the title that is to appear at the top of the menu. 


You next receive a display on which you define each option of the menu: » 


SDA MENU DEFINITION 


CTt OPTION. SSOMENUN PROMPT TYFE PGM/CL CMD 
, ar ees :- = | CHSDTA. 


FE LAs —. 
o o- Qo * 


CTL: I-Insert D-Delete TYPE: C-CL Cmd E-Prompt execution time 
C-Copy A-Copy after P-Program call 
P-Prompt for command now L-Program call with parameter list 





Requests the prompt for the CHGDTA command specified in field ©. 
so that you can enter parameters. 


Indicates the first option. 


Defines the text description to appear on the menu. S 


Specifies that the CHGDTA command is to be executed when option 1 is 


selected. 
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Because you requested prompting, you receive the CHGDTA prompt when you 
press the Enter key: 


Key Data using DFU (CHGDTA) Prompt 
Enter the following: 
Label: A] 
Application-program name: APP R mlgq3i5u 
Library name: ¥*LIBL 
Member name: MBR ¥FIRST 


p 
Verify(*NO *YES): P NO 
P *BLANK 


Run identifier: 





A) Key in MLG315U here to specify that the MLG315U application is to start 
execution when a user selects option 1 on the menu. 


When you press the Enter key after completing the prompt, the menu 
definition display appears again for you to define the second option of the 
menu: 


SDA MENU DEFINITION 


CTL OPTION MENU PROMPT TYPE PGM/CL CMD 


Maintain mailing List file C CHGDTA 
dnawire by zip cada spots 


i 


CTL: I-Insert D-Delete TYPE: C-CL Cmd E-Prompt execution time 
C-Copy A-Copy after P-Program call 
P-Prompt for command now L-Program call with parameter list 





& Requests prompting for the DSPDTA command specified in field ©. 


B Specifies that the DSPDTA command is to be executed when option 2 is selected. 
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When you press the Enter key, you receive the DSPDTA prompt: 


Display Data using DFU (DSPDTA) Prompt 
Enter the following: 
Label: Loan eee 
Application-progran name: APP R | mlg230u! 
Library name: TB - 
Member name: MBR P *FIRST 





@ Key in MLG230U here to specify that the MLG230U application is to start 
execution when a user selects option 2 on the menu. 


After completing the DSPDTA prompt, you again receive the menu definition 
display to define the next option: 


SDA MENU DEFINITION 


CTL OPTION MENU PROMPT TYPE PGM/CL CMD 
a aintain maili ist fi C CHGOTA 
nie Trews zip code ¢  DBSPpyA 


a 


a . 
ar) 
‘| 


=a 
— 
= 


BEPRGGReenen) 2 
> | 


CTL: I-Insert D-Delete TYPE: C-CL Cmd E-Prompt execution time 
C-Copy A-Copy after P-Program call 
P-Prompt for command now L-Program call with parameter list 


a] Prompting is 70t requested because default values are to be used for the 


SIGNOFF command specified in field @. 


© Specifies that the SIGNOFF command is to be executed when option 90 is 


selected. 








When you have defined the third option, you press the CF1 key to indicate that 
the menu definition is complete. You then receive a display on which you 
verify the names to be used in creating the display device file for the menu. 
The names shown are based on what you specified on the programmer menu. 
In this example, you want the name of the display file and its associated 
source member in QDDSSRC to be MLGO35CD, so you change the names 


shown: 


SDA SAVE DDS/CREATE DISPLAY DEVICE FILE 


Save the generated DDS source 
Source file where DDS is to be saved: 
Library: 
Member : 
(blank for HEMBER LIST display) 


Create a display device file from the DDS 
Display device file: 
Library: 
If create fails, display spooled listing 


Replace existing file 
Prompt for additional CRIDSPF parameters 


Submit display device file creation in batch 
Job description: 
Library: 


(Y N): 





A) The source for the display file will be placed in QDDSSRC. 


Y 

QDDSSRC o 
HLGLIBDEV 
HLGO35C 


Y 
MLGO35C 


MLGLIBDEV 
Y 


Y 
MLGLIBDEV _ 
*LIBL 


© Change the source member name and the display file name to MLGO35CD. 


When you press the Enter key, a batch job is submitted to create the 


MLGO35CD display file: 


SDA SAVE DDS/CREATE DISPLAY DEVICE FILE 


Save the generated 00S source 
Source file where DDS is to be saved: 
Library: 
Member : 
(blank for MEMBER LIST display) 


Create a display device file from the DDS 
Display device file: 
Library: 
If create fails, display spooled listing 
Replace existing file 
Prompt for additional CRIDSPF parameters 


Submit display device file creation in batch 
Job description: 
Library: 


% Mbr MLGO35CD saved. Batch create submitted. Press ENTER. 


(Y N): 


Y 


R QDDSSRC 


(Y N): 


MLGLIBDEV 
HLGO35C0 


Y 


R MLGO35CD 


(Y NJ: 
(Y N): 
CY N): 


CY ND: 





MLGLIBDEV 
Y 


Y 
MLGLIBDEV 
*¥LIBL 


© Message indicates a batch job submitted to create the display file. 


© The submitted job will use the job description that you specified on the 


programmer menu. 
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When you press the Enter key again, you receive a display to verify the names 
to be used in creating the CL program for the menu. The names shown are 
based on what you specified on the programmer menu: 


SDA CL SAVE/CREATE CL PROGRAM 


Source file where CL is to be saved: 
Library: 
Member: 
(blank for MEMBER LIST display) 


Create a CL program from the CL source 
CL program: 
Library: 
If create fails, display spooled listing 
Replace existing program 
Prompt for additional CRTCLPGM parameters 


Submit the CL creation In batch 
Job description: 
Library: 


aoe Oe 
MLGO35C 


(Y N) seyenanineoes 
R MLGO35C 
HEGLIBDEV, 
(Y N}: ¥ 
(CY Nd: _ 
(CY Nd: _ 


(YN): Y 
MLGLIBDEV 
¥LIBL 








@ The source for the CL program will be placed in QCLSRC. 
@ The source member in QCLSRC and the CL program will be given this name. 
Because you want the CL program name to be as shown, you press the Enter 


key without changing the display. The creation of the MLGO35C program is 
submitted as a batch job: 


SDA CL SAVE/CREATE CL PROGRAM 


Source file where CL is to be saved: R QCLSRC 





Library: 
Member: 
{blank for MEMBER LIST display} 


Create a CL program from the CL source 
CL program: 
Library: 
If create fails, display spooled listing 
Replace existing program 
Prompt for additional CRTCLPGM parameters 


Submit the CL creation in batch 
Job description: 
Library: 


%  Mbr MLGO35C saved. Batch create submitted. Press ENTER. 


MLGLIBDEV 
MLGO35C 


: Y 
MLGO35C 
MLGLIBDEV 
: ¥ 


Y 


MLGLIBDEY 
¥LIBL 





The menu definition is now complete. When you press the Enter key again, 
you receive the initial menu definition display to begin the definition of another 
menu. To exit the menu definition process, you press the CF1 key. You then 
receive the SDA option menu. To exit SDA, you press the CF1 key again. 





When the creation of the display file is completed, you receive a message that 
the batch job used to create the display file has ended normally. You receive a 
similar message when the creation of the CL program is completed. The 
MLGLIBDEV library then contains: 

e A member named MLGO35CD in the QDDSSRC source file. 

« A display file named MLGO35CD. 

e A member named MLGO35C in the QCLSRC source file. 

¢ ACL program named MLGO35C. 


The resulting menu is similar to the menu that was defined earlier in this 
chapter by separately coding the DDS for the display file and the CL program. 


MAILING LIST CLERK MENU 
Select one of the following: 
1. Maintain mailing list file 
2. Inquire by zip code 
90. Sign off 


Option: 





Note that the option field is at the bottom of the screen. The SDA process for 
creating menus places the option field on the second to bottom line of the 
screen. If you want the option field to be higher, you can change its position 
by one of the following methods: 


« Use SEU to change the DDS source member MLGO35CD in the file 
QDDSSRC and then use option 3 on the programmer menu to re-create the 
display file. 


« Use option 1 on the SDA option menu to change the display record format 
for the menu and then re-create the display file (for details, see the SDA 


Reference Manual and User's Guide). 


When you re-create the display file, you must specify LVLCHK(*NQ) to avoid 
an error condition in the creation process. 
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USING MULTIPLE ACCESS PATHS 


A common requirement in a mailing list application is to determine an account 
number when only the name and address associated with the account are 
known. An inquiry into the mailing list by customer name to find the account 
number may not be practical if the list is large; however, an inquiry into the 
mailing list by another field (such as zip code) may be more practical. 





By using logical files, data can be accessed in various sequences as described 
in Chapter 4. This method of retrieving data is similar to sorting on other 
systems where the data is processed sequentially in the desired sequence. In 
Chapter 7 and earlier in this chapter, the mailing list file (MLGMSTP) was 
updated by accessing records by account number. This method is similar to 
using a keyed index to a file on other systems. The logical file MLGMSTL 
defined the access path on account number. 






DFU : 
Transaction Application ius 
Entry MLG315U aster 


File 





alia 


Now a second access path will be created for accessing the same mailing list 
file on name and zip code instead of account number. This access path will be 
defined by the logical file MLGMSTL2. 









DFU 
Application 
MLG230U 










Physical 
Master 
File 






Both access paths to one file are immediately maintained. An access path has 
immediate maintenance if it is updated regardless of whether the file is open. 
For example, a record can be added by one work station user and all other 
users can immediately access that record on the same or a different access 
path. 
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To create and use an access path on both zip code and name, the following 
must be created: 


° A logical files MLGMSTL2, that has key fields for zip code and name 


« A DFU application, MLG230U, that inquires into the file by zip code and 
name 


Because the methods for creating source members, files, and programs, and 
for entering source are shown in detail in previous chapters, these methods are 
not repeated in the remainder of this publication. Any data that you need to 
enter is discussed; however, the displays on which you enter this data are 
shown only where needed for the discussion. 


Creating the Logical File 


A source member named MLGMSTL2 is created by selecting option 8 and 
specifying MLGMSTL2 for source member and LF for type on the programmer 
menu. You can also enter a text description for this source member. The DDS 
for MLGMSTL2 is shown in Figure 8-2. 






GX21-7754 UM/050" 








sacl DATA DESCRIPTION SPECIFICATIONS Printed in U.S.A, 
Keying | Graphic | 1 i : er | (Ca —————- a. = 
Instructian Key | | a Ps 
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ee ee YY te | 





























Figure 8-2. DDS for MLGMSTL2 File 


The DDS for logical file MLGMSTL2 are similar to those for logical files that 
were created previously. The physical file is named by the PFILE keyword. The 
existing format is used (MLGMSTR). Two key fields are specified (ZIP and 
NAME). The sequence in which the fields are written determines the order of 
the access path. In this case, ZIP is the high-order key field so that the access 
path is arranged by zip code and by name within each zip code. 


The logical file MLGMSTL2 is then created by selecting option 3 and specifying 
LF for type on the programmer menu. The access path is built and inimediately 
maintained. This means that any additions, deletions, or changes to names or 
zip codes are immediately reflected on the name and zip code access path. 
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Creating the DFU Application 


DFU application MLG230U. On the programmer menu, select option 1 and 
specify MLG230U for the source member. Also, select option 1 on the DFU 
menu when it is displayed. 


The programmer menu is used to invoke DFU to enter the definition for the } 


After the DFU menu, you receive the create/change menu: 


DFU CREATE/CHANGE MENU 


Select one of the following and enter values below: 
1. Display information about an application 
2. Create a new application 
3. Change an existing application 
4. Delete an existing application 


Option: 2 


Application name: MLG230U | BS) (¥-Application selection list) 
Library name: MLGLIBDEV: 


HELP-Help CF2-Previous display 





A) Select option 2 to create an application. 





8) The application name and object library name that you specified on the 
programmer menu are shown here. 


You then receive the DFU create prompt: 


DFU CREATE PROMPT 
Application name: MLG230U Library: MLGLIBDEV 


Enter information fornesapplicationseo8 
Description: Program for Maili 1 = 
File name: MLGMSTL2 t-File selection list) 
Library name: ay GLE LED EY | 


HELP-Help CF2-Previous display CF3-File information 





A) Key in the text that describes the DFU program. 





cy Key in the name of the file that defines the access path and the library where the 
file is located. 
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The application control prompt appears next. You need only verify that the 
display size is 24 x 80: 


APPLICATION CONTROL PROMPT 
Application name: MLG230U Library: MLGLIBDEV 
File name: MLGMSTL2 Library: MLGLIBDEV 


Place an X next to the display size: 
Primary display size: 24X80 _ 12X80 _ 16X64 


Take defaults after field selection: N (Y-Yes N-No) 


HELP-Help CF2-Previous display 





You then receive the file review prompt: 


FILE REVIEW PROMPT FOR FILE MLGMSTL2 A) 


For each record format to be used, enter R to review the fields, A to select all 
fields, or E to enter the fields later: 
RECORD FMT DESCRIPTION 
A MLGMSTR Mailing List Master 


O 





CS) This is the file name you specified on the create prompt. 


@ key in A to select all fields. 
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The next prompt is for entry format definition: 





ENTRY FORMAT DEFINITION PROMPT 


For record format name siceora ae @nter: 
Entry format identifier: 2 
Entry format description: Hatling List Master 
Display one field per line: mhiQus 
Display multiple records: ® “YES 
Redisplay changes: A 
Chain to entry format ID: 





@ Key in Z (for zip code). 


© Key in *YES (*NO is the default) so DFU will place as many records as possible 
on the execution display when the Roll Up (+) and Roll Down (¥) keys are pressed. 


You then receive the basic field definition prompt: 





BASIC FIELD DEFINITION PROMPT FOR RECORD MLGMSTR 


Define format ID Z - Mailing List Master 
FIELD NAME ORDER INPUT DISPLAY VERIFY XDEF XVAL 
acTNuN —s_—s @_4-5 
ACTTYP : 
NAME 3. 


ADDR 4. 

CITY 

STATE © 
ZIP 

MLGLK2 


bas Xx 
x Xx 
Xx Xx 
x bas 
x x 
x x 
x x 
x x 


| 





A) Change the order value for ACTNUM from 1.0 to 4.5. 


© Change the order value for ZIP from 7.0 to .1. 


© Key blanks into these positions. 
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This prompt allows you to design the display layout such that each record has 
only one line on the display. The width of each column on the display is 
implicitly determined by the width of the field, editing requested, width of the 
column head as specified in the DDS (COLHDG keyword), and spaces between 
the fields defined by DFU. 


Determine which fields the work station user needs to identify an account. In 
this case, the ACTNUM, NAME, ADDR, and ZIP fields need to be displayed. 
To specify which fields will appear and the order in which they will appear, 
change the ORDER column on the display as indicated. 


The INPUT column already has an X in it for each field. These Xs will be 
ignored when the audit control prompt is entered later so that the data is 
displayed only (the data cannot be changed). 


After the basic field definition prompt is entered, the entry format definition 
prompt appears again. Because no additional formatting needs to be done, the 
defaults that automatically appear are used and no information needs to be 
keyed in. The audit control prompt is displayed next: 


AUDIT CONTROL PROMPT 


Enter the following: 
Add/delete records allowed: NO © 
Change records allowed: ¥NO 
Key changes allowed: HYES 
Print additions: ¥NO 
Print changes: ¥HO 
Print deletions: *NO 
Data error option 

(#NOTIFY *DISPLAY *CHANGE): *NOTIFY 


@} = Key in *NO because no changes should be made to the file (*YES is the default). 


After the audit control prompt is entered, the exit application definition menu 
appears. Enter option 5 to create the DFU application. You then receive the 
application creation prompt. Accept the defaults as shown and press the Enter 
key to complete the creation of MLG230U. 
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Executing the DFU Application 


The DFU application can be tested from the programmer menu by selecting 
option 5 and entering the command DSPDTA APP(MLG230U). The following 
prompt is displayed: 


Key in the zip 
example: 


@ 10019 
@ JF Clark 


List Master MLG230U DISPLAY 


Name 





code @} and the name @ of the record to be displayed; for 








Next, the master record for the name and zip code specified in the previous 
prompt is displayed. The zip code and name fields were used to access the 
first record that was equal to or greater than the record just entered. The 
format of the display for this record was defined on the basic field definition 
prompt; the display looks like this: 


Z_ Mailing List Master MLG230U DISPLAY 


Zip Name Address Account 
Code Number 


10019 J F CLARK 75 MARKET PLAZA 10009 





The work station user can use the Roll Up (+) and Roll Down (¥) keys to look at 
the data using the name and zip code access path. Records are read 
sequentially using the access path to fill the display. If you press the Roll Up 
key, the following display appears: 


Z_ Mailing List Master MLG230U DISPLAY 


Zip Name Address Account 
Code Number 


15222 
17102 
186515 
19087 
19102 
19107 
19114 
20037 
43212 
44319 
52122 
55113 
55413 
55901 
60611 


FOX 413 17th AVE 10011 
JOHNSON 1151 SEVENTH AVE 10012 
CARLSON 701 FIELD ST 10008 
MASON 355 STATE ST 23456 
WHITE 99 PARKWAY 10345 
BROWK 27 CHESTNUT 10456 
ADAMS 500 INDEPENDENCE 10014 
MARTIN 2599 VIRGINIA 10015 
JONES 32 FIFTH AVE 10013 
LEE 327 WATERLOO RD 10010 
ROBINSON 323 WARREN RD 32323 
OLSEN 759 SNELLING AVE 10567 
ANDERSON 650 FIFTH AVE 10005 
HANSEN 211 SOUTH 5TH ST 76912 
MILLER 340 FAIRBANKS 10007 


CL 
RA 
AM 
SM 
JL 
JB 
SA 
AF 
JB 
E R 
AM 
JY 
JJ 
GC 
JA 





By pressing the Enter key, the work station user can return to the initial 
application display and enter a new zip code and name to begin inquiring at a 
different point on the access path. When the inquiry is completed, the work 
station user can press the Exit Application key (CF1) to end the DFU 
application. 
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Programming Considerations 


e The work station user could request the DFU application MLG230U from an 
application-oriented menu like the one shown earlier in this chapter in 
association with CL program MLGO35C. 





» The work station user could also request the application MLG230U by 
calling it from the program cail menu. A CL program similar to MLG315C, 
discussed earlier in this chapter, is required. 


e The Display Data (DSPDTA) command can be executed for any DFU 
application. For example, if DSPDTA is used to execute MLG315U, records 
are displayed and no changes can be made to them. 


« The Change Data (CHGDTA) command can be specified for the DFU 
application MLG230U; however, changes would not be applied to any 
master record because the following entries were made on the audit control 
prompt: 


AUDIT CONTROL PROMPT 


Enter the following: Yar = 
‘Add/delete records allowed: ¥#NO 
Change records allowed: #NO | 
Kay changes allowed: — wWES 
Print additions: #NO 
Print changes: #¥NO 
Print deletions: #HO 
Data error option 

(*NOTIFY “DISPLAY *CHANGE): *NOTIFY 
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USING THE QUERY UTILITY 


This section discusses how a query can be made against the mailing list file, as 
shown below. Suppose that you need to know what business or school 
accounts (the value of ACTTYP is 1 or 4) there are in either Pennsylvania or 
New Jersey (the value of STATE is PA or NJ). You need a printed report of 
the zip codes used in Pennsylvania and New Jersey with a line for each record. 
The report should be sequenced on account type, state, and zip code. 


Because this sequence is different from any of the access paths that already 
exist for this application, the physical file will be queried (no key fields are 
defined). The records are selected in arrival sequence and then sorted for the 
desired sequence. 


The query utility is the part of IDU that is used to extract, from a file, one or 
more records based upon 4a criterion. A query application is created by 
responding to a series of prompts {similar to those to which you respond to 
create a DFU application). The query utility predominantly performs a subset of 
functions that can be done using RPG III and logical files. 


A query is different from an inquiry using DFU in the following ways: 


* Query can analyze records based on a specified criterion; whereas, a DFU 
inquiry cannot. 


e Query can prepare a printed report; whereas, a DFU inquiry normally does 
not. 


The query utility can be used by those who are unfamiliar with DP terminology 
and coding. Those who are familiar with DP terminology and coding can use 
query as an alternative to certain application coding. 


Application Physical 
MLG9100 Master 
File 
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Creating the Query Application 


To create a query application, select option 2 on the programmer menu as ) 
follows: 


PROGRAMMER MENU 

Select one of the following: 

1. Design/execute DFU anp (app), »Coptions) 
. Design/execute query app (app), »(options) 
Create object object name, type, pgm for CMD, (text) 
Call program program name 
Execute command command 
Submit job (job name), (command) 
Display submitted jobs 
Edit source (scrmobr), (type), (text) 
. Design display format (sermbr ) 
Sign off (¥NOLIST ®LIST) 


eowoans Fw fun 


0 


Types: BSCF, CBL; CL, CLP, CMD, CMNF, DSPFs LF, PF, PRTF, RPGs TXT 


Option? 2. Parm: MLG910Q Type: Parm 2: 
Command: 


Text: Log requests: *YES 
Src file: Sre lib: MLGLIBDEV Obj lib: MLGLIBDEV  Jobd: MLGLIBDEY 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPMSG 





You receive a series of displays on which you define the query. The first 
display is the query menu. Select option 1 on this menu: 





QUERY MENU 
Select one of the following: 
1. Create or change a query 
2. Execute queries and display output 
3. Manage existing queries 


Option: ] 


Press HELP for instructions. Press CFl to exit. 








You then receive the query create/change menu: 


QUERY CREATE/CHANGE MENU 


Select one of the following and enter values below: 
1. Display information about e query 
2. Create a new query 
3. Change an existing query 
4. Delete an existing query 


Option: © 2 


Query name: MLG910Q (*-Query selection List) 
Library name: MHLGLIBDEV 


HELP-Help CF2-Previous display 





a Select option 2. 


@ The query name and object library that you specified on the programmer menu are 
shown here. 


The query create prompt appears next: 


QUERY CREATE PROMPT 
Query name: MLG910Q Library: MLGLIBDEV 


Enter information for new query: 


Description: Query Program MLG91L0G 
File name: MLGMSTP (*-File selection list) 


Library name: @ tisiispev 


HELP-Help CF2-Previous display CF3-File information 





@ Key in the text description of the query. 


© Key in the name of the file to be queried and the library where the file is located. 
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You then receive the output specification prompt, so that you can specify the 
headings for your report: 


OUTPUT SPECIFICATION PROMPT 


Enter the following: 
Cover page: 


Page heading: 


Detail listing: #YES Detail list double spaced: ¥*#NO 

Output line width: 132 Seperate record format headings: *YES 
Record sampling: ¥#NQ 

File review: ¥YES Display all fields in prompt: *YES 


Take defaults for all selected fields: MNO - 





@ Key in the page heading. 


8) Do not change the *NO shown here because you need to modify field definitions 
for your query. 


The file review prompt is displayed next: 


FILE REVIEW PROMPT FOR FILE MLGHSTP & 


For each record format to be used, enter R to review the fields, A to select all 
fields, or E to enter the fields later: 
~RECORD FMT OESCRIPTION 
BY R  MLGMSTR Mailing List Master 





& This is the file name you specified on the query create prompt. 


© Key in R to review all fields. 











The field review prompt is displayed after the file review prompt: 


FIELD REVIEW PROMPT FOR RECORD MLGMSTR 


Place an X next to each field to be used or enter *ALL: 
FIELD NAME LENGTH TYPE DESCRIPTION 
ACTNUM 5,0 Account Number 
ACTTYP 1,0 Acct Type 1=Bus 2=Gvt 3=Org 4=Sch 5=Pvt 
NAME 18 Name 
ADDR 18 Address 
CITY 18 City 
STATE 2 State 
ZIP 5,0 Zip Code 
MLGLK1 3,0 Control Number Used for Record Locking 





& Key in X next to the field(s) you want to be in the query output. 


® Do not key an X next to MLGLK1 (this field will be used in a later approach). 


You then receive the query definition prompt, which shows the fields you 
selected on the previous prompt: 


QUERY DEFINITION PROMPT 


For record format name MLGNMSTR enter: 
FIELD NAME ORDER SUM AVG SORT TEST XLIST TABLE 
ACTNUM 
ACTTYP 
NAME 
STATE 
ZIP 


Be 
ole 


oie 


ut 
So 
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For this mailing list application, the query definition prompt should look like 
this: 





QUERY DEFINITION PROMPT 


For record format name MLGHSTR enter: 
FIELD HAME ORDER SUM AVG SORT TEST XLIST TABLE 
ACTNUM 4.0 = fF ©. 

ACTTYP 
NAME 
STATE 
ZIP 


=] 


* 


bo 
= 


Ls | 
t=) 


peer r ett Gyaxnce I>< | 


peter errt @wcr ox 





& The ORDER column specifies the sequence (from left to right) that the fields will 
have on the query output. Change the default values so that the fields will have 
the following sequence: STATE ZIP ACTTYP ACTNUM NAME. 


© Key in X to specify which fields are to be sorted. 





©@ Key in X to specify which fields have test criteria. 





8-48 


After the query definition prompt is completed, the selection test prompt is 
displayed for ACTTYP and STATE, which were selected on the previous 
prompt: 


SELECTION TEST PROMPT 


Enter tests for *SELECT/*OMIT group: *SELECT 
FYELD NAME REL VALUES 
ACTTYP *LS 14 
STATE *PA' 'NJ' 


© 


¥*LS 
9 





&) The REL column specifies the type of relational test you want performed on the 
field. Key in *LS (for list type). 


@ The VALUES column specifies the values to be tested. Key in 1 4 (for ACTTYP) 
and ’PA’ ‘NJ’ (for STATE). PA NJ must be keyed in uppercase; otherwise, the 
test will be for the lowercase values, pa nj. All character values such as PA and 


NJ must be quoted (enclosed in apostrophes). 


The selection test prompt is displayed again to allow you to specify multiple 
select/omit groups. Because no additional testing needs to be done, no 
information needs to be entered. 


Interactive Input and Interactive Maintenance 8-49 


The sort specification prompt is displayed next: 





SORT SPECIFICATION PROMPT 


Enter change: 
FIELD NAME ORDER SUBTOTAL SUBTABLE SPACE EJECT DSCEND ABSNBR 
ACTTYP 


STATE 
ZIP 


a 
oo 


lad 
co | 





The default values in the ORDER column are correct for this query. 


The exit application definition menu for a permanent application is displayed 
next. Select option 5 to create the query application: 


EXIT APPLICATION DEFINITION MENU 


Select one of the following: 
1. Restart definition 
Modify definition 
- Delete definition 
. Save definition 
. Create application 


Option: 
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Because you indicated that you want to create an application, you next receive 
the application creation prompt: 


APPLICATION CREATION PROMPT 


Enter the following: 
Application name: MLG910Q 
Library name: MLGLIBDEV 
Public authority: 
Adopt owner's user profile: 
Source listing: 


(l-Normal 2-None 3-All) 
(Y-Yes WN-No) 
(Y¥-Yes N-No) 


IZ IZ l= 


(¥-Yes WN-No) 
(¥-Yes WN-No) 


Dump internal data areas: 
Generate code listing: 


IZAZ 





In this example, the defaults shown on the prompt are all acceptable, so you 
press the Enter key without making any changes. 


When the creation of the MLG9100Q application is completed, a query 
execution prompt is displayed for you to specify the details of how the query is 
to be executed. If you do not want to execute the query at that point, press 
CF1 to exit the query utility. 
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Executing the Query Application 


To execute a query application: 





« Select option 2 on the programmer menu, as you did to create the 
application, and then select option 2 on the query menu when it ts 
displayed. 


« Enter the Query Data (QRYDTA) command. 


In this example, you request a printed query report by submitting the QRYDTA 
command in a batch job from the programmer menu. Submitting the query as 
a batch job allows you to go on to other tasks at your work station while the 


query processing is being done. 


The batch job to execute the query application MLG9100Q is submitted from 
the programmer menu as follows: 


PROGRAMMER MENU 
Select one of the following: 
1. Design/execute DFU app (app), »loptions) 
2: Design/execute query app (app), ;loptions) 
3. Create object object name, type, pgm for CMD, (text) 
- Call program program name 
. Execute command command 
Submit job (job name); (command) 
. Display submitted jobs 
. Edit source (scrmbr), (type), (text) 
Design display format (sermbr ) 
. Sign off (*NOLIST *LIST) 





Types: Qn CBL, Cl. CLP, CMD, CMNF, DSPF, LF, PF, PRTF, RPG, TXT 


Option: 6 Parm: MLG9}0Q Type: Parm_?: 
Command: grydta app(mlg9l0q) output(*list KS) 


Texts Log requests: ¥*YES 
Sre file: Sre lib: MLGLIBDEV Obj lib: MLGLIBDEV_ Jobd: MLGLIBDEV 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPMSG 





Option 6 submits a job for batch processing. 


The submitted batch job is given the name MLG9100, as specified here. 


The QRYDTA command requests execution of the query program MLG910Q. The 
output is to be printed. 
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A sample of the query printed output is shown below. 


DATE 09/21/81 TIME 10:36:59 


APPLICATION: MLGOLOQeMLGLIBDEYV 


QUERIED FILE: MLGMSTPeMLGLIBDEV MEMBER: MLGMSTO 


FILE RESORTED ACCOROING TO FOLLOWING SORT ORDER: 


RECORO FORMAT FIELD SEQUENCE SIGN 


MLGMSTR ACTTYP ASCEND =YES 
STATE ASCEND 


ZIP ASCEND <=YES 


USER SPECIFIED RECORD SELECTION CRITERIA: 


RECORD FORMAT OPTION FIELD SELECTION TEST 


MLGMSTR SSELECT ACTTYP 


STATE =LS '"PA® 


09/21/81 10:38:59 COUNT BY S3USINESS AND SCHOOLS IN NJ AND PA 


STATE Z1P ACCT ACC OUNT 
CODE TYPE NUMBER 


Nu O7114 
NJ O7114 
Nu 07115 
NJ 08075 
PA 15222 
PA 17102 
PA 19102 
PA L9LOT 
PA 19114 
NJ 09540 
PA 18515 
PA 19087 


Llll2 
L9123 
19002 
10234 
10011 
10012 
10345 
19456 
10014 
13678 
10008 
23456 


MILLER 
MILLER 
BROWN 
SMITH 

F OX 
JOHNS ON 
WHITE 
BROWN 
ADAMS 
LEWIS 
CARLSON 
MASON 


SS a a de oe ed 
VP PYLE RANP OR 
ZEX¥oroErwOr rr mer pw 


TOTAL NUMBER OF RECORDS PROCESSED 12 





Query supports several other functions that allow you to make a more complex 
analysis. For information on these functions, refer to the Query Utility 
Reference Manual and User's Guide. 


— 
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RECOVERY CONSIDERATIONS 


lf incorrect data has been entered for a master record, the application can be 
executed again to change the incorrect data. In this application approach, the 
changes are applied immediately to the master file (rather than to a transaction 
file and then to the master file through a batch maintenance program, as in 
Chapter 7). 


If there is a system failure while the work station user is entering transactions, 
one of the following approaches could be used: 


e When the master file MLGMSTP is created by the Create Physical File 
(CRTPF) command, there is a parameter named force write ratio 
(FRCRATIO) to control the frequency in which records are written to 
auxiliary storage. Using the default for this parameter provides the best 
performance. If the default (**NONE) is used, the work station users should 
check the last several transactions they entered to ensure they were 
recorded in auxiliary storage. 


The system may not write the records to auxiliary storage in the same 
sequence in which the updates occurred. All of the transactions entered 
may not be reflected because some records may have been in main storage 
at the time the system failure occurred and cannot be recovered. 


The listing that is printed upon the exit from the application may be used to 
determine what transactions were entered. The transactions will be listed in 
the correct sequence, but the listing may not be completely up-to-date. 
Printed records are spooled and are kept in buffers in main storage; 
therefore, some records may be lost if a system failure occurs. 


« If the force write ratio parameter value is specified as 1, the work station 
users should look at their last entry to determine if it exists before 
continuing. In this situation, the printed listing may not be as up-to-date as 
the data base. 


¢ A file can be created with a force write ratio parameter value of 1 and used 
as a data base log. Following a system failure, the last several records in 
the log can be reapplied to the data base. See the CPF Programmer's Guide 
for more information on data base logging. 


To recover from damaged objects, such as when the master file (MLGMSTP) is 
unusable, restore the backup version of the file. The work station users will 
have to reenter the transactions entered since the last backup was made. 


DFU does not provide a data base transaction file of the changes that were 
made to the file being updated; however, data base logging could be used to 
provide this type of file. A user-written recovery program could reapply the log 
to a backup copy of the master file. The log could also serve as an activity 
trace of changes to the data base and can help you correct records that were 
updated by faulty programs. Refer to the CPF Programmer's Guide for more 
information on data base logging. 











Chapter 9. Batch Maintenance of Multiple Diskette Batches 


OVERVIEW 


The application approach in Chapter 4 allowed multiple key-entry operators to 
key transactions onto diskettes, but the system operator had to enter a 
command to read each diskette into storage. The approach in this chapter 
allows the system operator to read multiple diskettes by entering a single 
command. 


This approach to the mailing list application has the following characteristics: 


« Batches of transactions are keyed onto diskettes that have been formatted 
to define the transactions as data for a batch job. 


¢ The CL program, DSKTCPY, when called from a work station, copies the 
diskette data into a data base file, JOBFILP, creating an input stream of 
batch jobs. When all of the diskettes have been copied, the program starts 
a data base reader, which transfers the batch jobs to a job queue.. 


e When each batch job is executed, a CALL command within the job 
instructions calls an RPG I|l maintenance program (MLG310). The 


maintenance program updates a master file (MLGMASP) with the 
transactions that were copied from diskette as data for the job. 


a 


CL Program 


DSKTCPY 


e| 









Start Data Base Reader 


JOBFILP 















by ____~ (OR er 
Call MLG310 Maintenance Physical 
: Program Master 


MLG310 nig 








Job Input Input 
Stream Spooling 
QPRINT 
Diskette Files a | =p 
(commands and a | ; 
transactions) 
—=—_— 
Report 
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DISKETTE FILE ARRANGEMENT 


Each diskette contains only two files. The first file contains the following CL 
for the job: 


// JOB JOBD(MLGLIBDEV.MLGLIBDEV) JOB(MLG310) 
CALL MLG310 /* MAINTAIN MAILING LIST FILE */ 
// DATA FILE(INPUT) 


The second file contains transactions and is reset (the end-of-file pointer is 
changed at the offline device) each time the key entry operator enters a new 
batch of transactions. 


When the two files have been read into storage, the data base file that is 
created contains the following: 


// JOB JOBD(MLGLIBDEV.MLGLIBDEV) JOB(MLG310) 
CALL MLG310 /* MAINTAIN MAILING LIST FILE */ 
// DATA FILE(INPUT) 

« (data from second file) 


On the next diskette that is read, the // JOB command designates both the 
end of the previous job and the beginning of a new job. Multiple diskettes can 
be read consecutively to create a data base file that contains an input stream 
with multiple jobs. This input stream is transferred to a job queue when the 
Start Data Base Reader (STRDBRDR) command is executed. 











JOBFILP FILE 


To use this approach, first create a data base file to contain the input stream 
that will be read from the diskettes: 


PROGRAMMER MENU 
Select one of the following: 
- Design/execute DFU app (app), »Coptions) 
- Design/execute query app (app), ,loptions) 
. Create object object name, type, pgm for CMD, (text) 
- Call program program name 
. Execute command command 
. Submit job (job name), (command) 
. Display submitted jobs 
. Edit source (scrmbr), (type), (text) 
. Design display format (sermbr ) 
. Sign off (*NOLIST *LIST) 


SOoonwn ows une 


] 


Types: BSCF, CBL, CL, CLP, CMD, CHNF, DSPF, LF,» PF, PRTF»e RPG» TXT 


Option: 5 Parm: Type: Parm 2; 
Command: crtpf file(jobfilp) redlen(128) text('File for Input Job Stream' ) 


Text: _ Log requests: *YES 
Src file: Src lib: MLGLIBDEV_ Obj lib: MLGLIBDEV Jobd: MLGLIBDEV 
CF3-Command entry CF4-Prompt (3 & 5 only) CF6-DSPMSG 





This file is not read by the RPG III maintenance program (MLG310); it is only a 
means of holding the input stream. Field level DDS are not needed because 
the record format of the file can be defined as one field and the file is 
processed only sequentially. When the RCDLEN parameter is used, no DDS 
source is required. This command creates a definition for a 128-byte record in 
the file JOBFILP. Because no library name is used in the CRTPF command, the 
data base file is created in the general purpose library (QGPL). 


By default when a file is created, only the owner can clear the entire file. To 
allow the system operator to clear the file JOBFILP, the Grant Object Authority 
(GRTOBJAUT) command is issued: 


GRTOBJAUT OBJ(JOBFILP) OBJTYPE(*FILE) USER(QSYSOPR) 
AUT(*OBJMGT) 


The object management (*OBJMGT) authorization allows the system operator 
to clear the file. 
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THE DSKTCPY PROGRAM 


After the diskettes to be read are mounted in the diskette magazine drive, the 
system operator selects option 4 on the system operator menu to call a 
program named DSKTCPY: 


SYSTEM OPERATOR MENU 
Select one of the following: 
- DSPJOBQ (jobq) - STRPRTWTR device,outq 
. DSPOUTQ Coutq) - CNLWTR writer 
. SNOMSG tomsgaq,(type);msg . STROKTRDR device, label 
~ CALL program . CNLRDR reader 
. Execute command - SIGNOFF (*NOLIST *LIST) 
. SBMIDR) (job) scl a or 


Option: 4. | Parms# dsktcpy 


‘ 
e 


Msg or! emd:z 


Log requests: *YES CF3-Command entry CF4-Prompt (5 only) 
CF6-DSPMSG Q@SYSOPR CF7-DSPSBS CF8-DSPSYS 





The DSKTCPY program reads each diskette and adds the file data to the file 
JOBFILP. If the magazine is not full of diskettes, the system operator is 
prompted with an inquiry message when the first empty slot is encountered. 
The system operator should respond by entering a C (for cancel) so that no 
diskettes will be read after the first empty slot. When the reading of the 
diskettes is completed, the program starts a data base reader that places all 
the jobs on the QBATCH job queue. 


The CL program DSKTCPY is shown in Figure 9-1. It begins with a Clear 
Physical File Member (CLRPFM) command to reset JOBFILP. Each diskette 
slot in the magazine is positioned by the Override with Diskette File 
(OVRDKTF) command. It describes the location of the diskette within the 
magazine and also specifies that the override is secure. This means that any 
override commands previously entered by the system operator will not be used. 
The Copy File (CPYF) command copies all the files into the file QDKT and adds 
them to JOBFILP. 


For the second through the tenth CPYF commands, a Monitor Message 
(MONMSG) command is used to monitor for the message CPF2952. CPF2952 
is an escape message that will be sent to the program if the system operator 
responds with a C (cancel) to the message that appears when the first empty 
slot is encountered. When a C is entered (or when all slots are filled and the 
diskette in the last slot has been read), the program branches to the Start Data 
Base Reader (STRDBRDR) command. 





c 


SEQNBR* eee eee 1 


100 

200 

300 

400 

500 

600 

700 

800 

900 
1000 
11900 
1200 
1300 
1400 
1500 
1609 
1700 
1800 
1900 
2000 
2100 
2200 
2300 
2400 
2500 
2600 
2700 
2800 
2900 
3000 
3100 
3200 
3300 


STARTRDR=: 


o oe ean 2 


PGM 
CLRPFM 
OVROKTFE 
CPYF 
OVRDKTF 
CPYF 
MONMSG 
OVROKTF 
CPYF 
MONMSG 
OVRDOKTF 
CPYF 
MONMSG 
OVROKTF 
CPYF 
MONMSG 
OVROKTF 
CPYF 
MONMSG 
OVROKTF 
CPYF 
MONMSG 
OVRDKTF 
CPYF 
MONMSG 
OVRDKTF 
CPYF 
MONMSG 
OVRDKTF 
CPYF 
MONMSG 


STRDBROR 


ENDPGM 


Figure 9-1. CL Program DSKTCPY 


QDKT LOC(#M1 5 5) 


ees 3 eee ees 4 eee eee 5 eeea eee 


JOBFILP 
QOKT LOC(#M1 1 1) SECURE(*YES) 
QDKT TOFILE(JOBFILP) FROMMBR(#ALL) 
QDKT LOC(#M1 2 2) SECURE(*YES) 
QOKT TOFILE(JOBFILP) FROMMBR( ALL) 
MSGID(CPF2952) EXEC(GOTO STARTRDR) 
ODKT LOC(=M1 3 3) SECURE(#YES) 
QDKT TOFILE(JOBFILP) FROMMBR(#ALL) 
MSGID(CPF2952) EXEC(GOTO STARTROR) 
QDKT LOC(#Ml1 4 4) SECURE(*YES) 
QDKT TOFILE(JOBFILP) FROMMBR(*ALL) 
MSGID(CPF2952) EXEC(GOTO STARTRDR) 
SECURE (*YES) 
QOKT TOFILE(JOBFILP) FROMMBR (ALL) 
MSGID(CPF2952) EXEC(GOTO STARTRDR) 
ODKT LOC(*Ml 6 6) SECURE(#YES) 
QDKT TOFILE(JOBFILP) FROMMBR(*ALL) 
MSGID(CPF2952) EXEC(GOTO STARTRDR) 
QOKT LOC(=M1 7 7) SECURE(*YES) 
ODKT TOFILE(JOBFILP) FROMMB&(=ALL) 
MSGID(CPF2952) EXEC(GOTO STARTRDR) 
QODKT LOC(*M1L 8 8) SECURE(*YES) 
QDKT TOFILE(JOBFILP) FROMMBR(*ALL) 
MSGID(CPF2952) EXEC(GOTO STARTRDR) 
QDKT LOC(*M1 9 9) SECURE(YES) 
QDKT TOFILE(JOBFILP) FROMMBR (ALL) 
MSGID(CPF2952) EXEC(GOTO STARTRDR) 
QDKT LOC(#ML 10 10) SECURE(*YES) 
QDKT TOFILE(JOBFILP) FROMMBR(*ALL) 
MSGID(CPF2952) EXEC(GOTO STARTRDR) 
JOBFILP 
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MBROPT(*ADD) 


MBROPT (ADD) 


MBROPT (*ADD) 


MBROPT (ADD) 


MBROPT (+ADD) 


MBROPT (ADD) 


MBROPT (*ADD) 


MBROPT (ADD) 


MBROPT (*ADD) 


MBROPT (ADD) 


The DSKTCPY program is created by using the programmer menu and SEU. 
The procedure was described in previous chapters. 
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UPDATING THE MASTER FILE 


The data base reader started by the DSKTCPY program transfers the jobs from 
the JOBFILP data base file to the QBATCH job queue. The transactions that 
are defined as data for each job are stored in an inline data file. 


OS CRE Y 


QBATCH 





STROBRDR JOSFILP 


4s 





e 
Call MLG310 

e 

Input rm 
Spooling = 


JOBFILP | « 












inline Data 


Transaction 


Records 





// JOB JOBD(MLGLIBDEV.MLGLIBDEV) JO8(MLG310) 
CALL MLG310 /*MAINTAIN MAILING LIST FILE */ 
ff DATA FILE(INPUT) 


e (transaction records) 
t | 


When one of the batch jobs becomes the highest priority job on the QBATCH 
job queue, the job is executed and the MLG310 maintenance program is called. 
As described in Chapter 4, the MLG310 program updates the data base master 
file, MLGMASP, with the transactions in the inline data file associated with the 
job (the RPG II\ specifications for MLG310 are shown in Figures 4-3 through 
4-7). 


SeATGH S 


Job MLG310 
PORES? Bedi 
PRES Execution 






Maintenance 


SS ==> 
pees 





Program 
MLG310 
“7 Inline Data Data 
INPUT QPRINT 
a} or nov 
a} 


f_®Y 


—" 
Report 


The procedure just described for using diskette input can be used to read in 
transactions for multiple applications intermixed within the diskette magazines. 
Each type of transaction file would be processed by a unique program. 


RECOVERY CONSIDERATIONS 


The recovery considerations for the approach in Chapter 4 also apply to this 
approach. 
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Chapter 10. Batch Maintenance of Multiple Work Station Entries 


OVERVIEW 


The application approach in Chapter 7 allowed only one work station user at a 
time to be entering transactions for subsequent batch processing. The 
approach in this chapter allows multiple work station users to enter batches of 
transactions at the same time. This approach provides the following 
capabilities: 


« Allows new batch input from multiple work station users to be entered at 
the same time a maintenance program is processing batches of transactions 
that are completely entered. 


« Allows transactions to be added to a batch of transactions that have been 
entered but not yet processed by the maintenance program. 


« Prevents duplicate batch numbers from being entered. 


« Prevents the maintenance program from processing a batch of transactions 
that is not completely entered. 


e Allows the work station user to review the last transaction he entered in 
case he loses his place or recovery is needed. 


Individual batches are distinguished by having work station users provide a 
batch identifier when they begin entering transactions. The status of a batch 
(that is, whether it is available for processing) is defined by having the work 
station user indicate when the batch is complete. The batch identifier and 
Status are stored in a physical header file, MLGHDRP, and the transactions in a 
physical transaction files MLGTRNP. 


An RPG Ill program, MLG105, and an associated display file, MLG105D, 
provide the display and processing support for entering the transactions from a 
work station. The MLG105 program accesses the header file and physical 
transaction file through a logical transaction file, MLGENTL. 










Display 
File 
MLG105D 












Work Station Physical 
Transaction 


File 














RPG Itl 
Program 
MLG105 
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This approach assumes that the completed batches of transactions in the 
transaction file are applied to the master file by a batch maintenance program 
similar to MLG310, as described in Chapter 7. The maintenance program will 
apply a batch of transactions to the master file only if the associated batch 
header records indicate that the batch is ready to be processed. 


BATCH HEADER RECORD 


This approach begins with creating a unique header record for each batch of 


transactions that is to be entered. This record contains headings for a batch of 


transaction records and control codes that specify the current status of that 


batch. The header record has the following format: 


Field Description | Field Name 


Batch Number BATNUM 
Batch Date BATDAT 
Batch Status BATSTS 


Batch BATDSC 
Description 








Numeric 
Numeric 
Numeric 


Character 





The batch status is specified by one of the three following codes: 


Code Meaning 


1 Data entry Is in process 
2 Data entry is to be continued 
3 This batch is ready to be processed by the 


maintenance program 


Other valid codes could be added to the batch processing program MLG105; 


however, additional codes are not shown in this publication. 


The batch number, batch date, batch status, and batch description fields 
should be added to the field reference file MLGREFP (which was created in 
Chapter 6). 


You can add these fields to MLGREFP by the following procedure.: 
« Use option 8 on the programmer menu to obtain the SEU display of the 


member MLGREFP in the source file QODDSSRC. Add the DDS in Figure 
10-1 to the existing DDS in the source member (Figure 6-2). 


¢« Use option 3 on the programmer menu to recreate the file (press the CF11 
key instead of the Enter key to replace the existing MLGREFP file by the 
new MLGREFP file). 
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Figure 10-1. Additional DDS for MLGREFP Field Reference File 


The EDTCDE keyword specifies that BATDAT is edited with the edit code Y 
when it is used by DFU. For a description of edit codes, refer to the CPF 
Reference Manual—DDS. 


Because fields were added to MLGREFP, no changes need to be made to the 
existing physical and logical files. 
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A physical file named MLGHDRP is created to contain the batch header data, 
as shown in the following illustration. 





The batch header file contains 
a header record for each batch. 
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The DDS for MLGHDRP are shown in Figure 10-2. 
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Figure 10-2. DDS for MLGHDRP Batch Header File 





TRANSACTION FILES 


A physical file named MLGTRNP is used to contain the transaction records by 
batch, as shown in the following illustration: 


Physical 
Transaction 
File 
MLGTRNP 





MLGTRNP was created and used in Chapter 6 (the DDS for MLGTRNP are 
shown in Figure 6-6). 
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A logical file named MLGENTL is created for the batches of transactions as 
they are being entered. Both header information and transaction records are in 
this file. The DDS for MLGENTL are shown in Figure 10-3. 
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Figure 10-3. DDS for MLGENTL Transaction File 





The two physical files MLGHDRP and MLGTRNP are used. A key field in each 
of these files is BATNUM. The physical transaction (MLGTRNP) file also uses 
TRNNUM as a key field. The keyword UNIQUE specifies that the entries in the 
key fields must be unique within each physical file. This means that the batch 
header records must have unique batch numbers and the transaction records 
must have unique batch numbers and unique transaction numbers. 


Because MLGHDRP is specified first in the DDS, batch header data is on the 
access path of MLGENTL before any transaction records of that same batch. 
MLGHDRP does not contain the field TRNNUM (every record type in a file is 
not required to contain the same number of key fields). 
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TRANSACTION DATA ENTRY PROGRAM AND DISPLAY FILE 


An RPG III program named MLG105 and a display file named MLG105D are 
created to allow a work station user to enter batches of transactions at a work 
station. The work station user begins by calling MLG105 (the method used to 
call the program is not discussed here, although MLG105 can be called as the 
result of selecting an option on a menu). 


Program Flow 


A flowchart of the program is shown in Figure 10-4. This flaw of the program 
centers around the entries made by the work station user. 
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Figure 10-4 (Part 2 of 2). Flowchart of MLG105 Transaction Data Entry Program 
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The work station user begins by keying in batch header data on the following 
display, which is part of MLG105D and named INITIAL: ) 


MAILING LIST TRANSACTIONS CF1-End of program 


Batch number 


Type of request __ 


N = New batch 
A = Add to existing batch 


Batch description if new 





The work station user keys in a batch number and requests to work on either a 
new batch or an existing batch. If the user requests to work on a new batch, a 
batch description may also be keyed in. After at least one batch is entered, the 





initial prompt looks like this: 


MAILING LIST TRANSACTIONS CF1l-End of program 
Batch number 


Type of request 


N = New batch 
A = Add to existing batch 


Batch description if new 


Last batch entered 150 Status = Ready 
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The display shows the batch number and the status of the last batch of 
transactions entered. 


The entries that are made on this prompt must be checked for validity because 
the primary purpose of this prompt is to do one of the following: 


« Write a new batch header 


« Find an existing batch header if the work station user requests to add to an 
existing batch 


« Confirm that a work station user can add to an existing batch 


Transactions are keyed in on the following display, which uses subfile records 
of record name SUBEFIL in display file MLG105D: 


MAILING LIST TRANSACTIONS Batch number id CF3-End CF5-Contu CF6-Revw 


TRN ACCT TYPE NAME ADDRESS CITY STATE ZIP 


Subfile 
Records 





Each transaction entered is a record in a subfile. A subfile is a group of 
records of the same record format that can be displayed concurrently at a work 
station. The system sends the entire group of records to the work station in a 
single operation and receives the group in another operation. The program can 
process records one at a time even though a group of records was entered. 
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The work station user keys one or more transactions into the subfile and 
presses the Enter key. As soon as the data is accepted by the system, the 
fields that were entered are erased and the keyboard is unlocked to allow more 
entries. This programming technique helps optimize the time used to enter 
transactions, but does not allow the program to edit the transactions and 
provide feedback for errors. This type of key entry is often called heads down, 
meaning that the work station user is keying from a source document and does 
not look at the display. The work station user can fill the entire display with 
transactions before pressing the Enter key. This reduces the number of times 
that the system must interact with the user, thereby providing for a fast rate of 
key entry. Editing of the data occurs later, while the batch is being processed 
by another RPG II| program as in some of the previous approaches. 








Data Description Specifications for MLG105D 
The DDS for the display file MLG105D are shown in Figure 10-5. 
The DDS could be generated using the screen design aid, which was 


introduced in Chapter 8 and is described in detail in the SDA Reference Manual 
and User’s Guide. 
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Figure 10-5 (Part 4 of 4). DDS for MLG105D Display File 


The REF keyword specifies use of the field reference file MLGREFP to minimize 
coding. 


The name INITIAL specifies the format for the prompt that requests batch 
header data. The name TYPRQS specifies a validity check for the request entry 
made by the work station user. This eliminates checking for a valid request in 
the program. 
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Cc 


The name CONFIRM specifies the format for the prompt that confirms the work 
station user has requested to work on a batch with a status code of 1 (data 
entry is in process). It looks like this: 


MAILING LIST TRANSACTIONS - CONFIRMATION 
Batch number 10 
Batch header is coded as being Keyed. 


If this is a recovery situation press CF10. 


If not recovery, press ENTER to return to first prompt. 





This confirmation is necessary because the program does not distinguish 
between a batch that has data being entered into it and a recovery situation. A 
recovery situation may occur if either the system or the program fails and the 
batch header record is not updated. 


The record format names SUBFIL (subfile) and SUBCTL (subfile control) specify 
the format for the prompt that allows the work station user to enter 
transactions. SUBFIL is designated by the keyword SFL and specifies the 
position for the first subfile transaction record on the display. Data is entered 
into fields that are also in the transaction file MLGENTL. The Rs entered in 
position 29 specify using the field reference file for the definitions of each of 
these fields. (The field reference file, MLGREFP, was specified at the 
beginning of the DDS for this file.) 


The SUBCTL format is associated with the subfile (GSUBFIL} by the keyword 
SFLCTL. SUBCTL specifies the format of the subfile with constants and fields. 
Keywords that define and control the subfile are also listed here. The subfile 
and the subfile control are displayed each time the SUBCTL format is written 
because indicator 50 is set on at the beginning of the RPG III program 
(MLG105). 


The keywords SFLPAG and SFLSIZ specify that 15 records will be on a page 
and there is only one page. The SFLINZ keyword initializes all fields in the 
subfile so that the work station user can enter data into the fields. 


The keyword UNLOCK specifies that the keyboard is unlocked when the 
system accepts data. If UNLOCK is not specified, the keyboard is not 
unlocked until the program sends a format to the display. Key entry throughput 
is improved by specifying UNLOCK; however, the program cannot check the 
data for validity and send an error response because the work station user may 
already be keying in the next group of transactions. 
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Functions for the following three command keys are also specified: 


e CF3 indicates the end of a completed batch. 





e CF5 indicates that the work station user is stopping work on this batch (the 
user may sign off) and will continue work on this batch at a later time. The 
batch should not be processed by the maintenance program because it is 
not complete. 


- CF6 indicates that the work station user needs to see the last transaction 
entered. This can be used during transaction entry and is the same function 
that is automatically invoked upon returning to a batch to continue entering 
transactions. 


Note that the three command keys are coded CFxx and not CAxx. CFxx coding 
sends the data that is on the display and the key number that was pressed to 
the system. The program first processes the data from the display and then 
tests for whether a command key was or was not pressed. The CAxx 
command keys send only the key number (not any data); any transactions 
entered by the work station user would be lost. 


The name LASTTRN specifies the format that is used to review the last 
transaction that was keyed in; the format looks like this: 


MAILING LIST TRANSACTIONS ENTER-Continue 


REVIEW OF LAST TRANSACTION 





Batch number 10 
Transaction type D 
Account number 91234 
Account type 3 
Name J E SAMPSON 


Address 312 EAST LANE 


City MINNEAPOLIS State MN 


Zip 55488 


Transaction number 110 





The work station user sees this review display in the following situations: 
« When specifically requesting to review the last transaction. 


« When requesting to add transactions to an existing batch. 
— The work station user previously terminated the batch in a to be continued 
Status, or 
— A system or program failure occurred and the operator is requesting 
recovery. 
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RPG Ill Specifications for MLG105 


The RPG III specifications for the transaction data entry program are shown in 
Figures 10-6 through 10-8. 
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Figure 10-6. Control and File Description Specifications for MLG105 Transaction Data Entry Program 


RPG Control and File Description Specifications, shown in Figure 10-6, describe 
two files: MLGENTL and MLG105D. The U in position 15 specifies that 
MLGENTL is updated by the program and the A in position 66 specifies that 
records are added to MLGENTL during execution of the program. The K in 
position 53 (of the last line) and the SFILE keyword specify that MLG105D 
uses a subfile. RECNUM is the name of the field that contains the relative 
record number when records are written to the subfile named SUBFIL. 
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In the Calculation Specifications, shown in Figure 10-7, the processing of a 
batch begins with indicator 50 being set on. This indicator is used to specify 
that the subfile and subfile control formats should be displayed each time the 
subfile control format is written. 


The EXFMT INITIAL statement displays the INITIAL prompt (which is 
described by the DDS in Figure 10-5) and the program waits for a response. If 
the response is a request to end the program, the program sets on the LR 
indicator and returns. It is important for RPG II| programs to set the LR 
indicator on when the program is complete. This allows the working storage 
required by the program to be eliminated by the system. Use of the explicit 
RETRN operation code causes the program to return to where it was called. 
The RPG ill program cycle still exists even with interactive programs. It is 
more straightforward to end the program explicitly using RETRN than to rely 
upon the RPG III program cycle to perform the return operation. 


If the response is not a request to end the program, the batch number is used 
to attempt to access an existing batch header with the same batch number. 
Depending on the type of request (add or new), this attempt can result in one 
of the following error messages on the INITIAL prompt: 


¢« Batch number does not exist (for add requests) 


¢« Duplicate batch number (for new requests) 
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The CHAIN statement uses the batch number (BATNUM) in Factor 1. Factor 2 
specifies that the batch header record (MLGHDRR) is accessed. The Factor 1 
field used in the CHAIN statement must have the same attributes as the key 
field of the record format name being chained. Note that the record format 
name is being specified and not the file name. When the CHAIN statement is 
used, there must be an exact match between the key field attributes of Factor 
1 and the record format. 


If continuation is requested and the batch header exists, the batch status field 
is checked for a valid entry. If the batch status is greater than 3, the following 
error message is displayed on the INITIAL prompt: 


Status of the batch does not allow any additions 


If the batch status is 2 or 3, the batch may be continued; the batch header 
record updated, and processing continued. If the batch status is 1, the 
CONFIRM format (Figure 10-5) is displayed. The work station user needs to 
confirm his request because the program does not distinguish between the 
following: 


¢« An invalid request by another work station user (to continue work on a 
batch that is currently being worked on) 


e A recovery situation in which the batch header was not updated to have a 
status code of 2 or 3 


A simpler design would not distinguish between a status code of 1 or 2; a 
more complex design would recognize a recovery situation and change all 
Status codes of 1 to 2. 


A batch header can exist without having transactions associated with it. When 
the work station user requests to review the last transaction entered in this 
batch, the LASTTRN format (Figure 10-5) is displayed with the following 
message: 


No records exist for this batch 


The LSTREC routine writes the LASTTRN format and the WRTHDR routine 
adds the new batch header to the file. 


The DSPSUB routine writes to the display that has the format subfile control 
and subfile. A separate statement reads the format. EXFMT is not used 
because of the heads down environment. The loop begins with the operation 
READC, which requests to read the next changed record from the subfile. Only 
those records entered since the last write to the display are provided. When a 
record is entered by the work station user, it is considered active for the 
remainder of the program; consequently, the program tests the first two fields 
of the input record. If they are blank or have values of O, the program 
assumes that no record was entered. A valid record from the subfile is written 
to the transaction file. 
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When there are no records remaining to be processed in the subfile, the 

program checks which command key was pressed. It is valid to press a 

command key whether records were or were not entered. The program loops 2 
back to read the subfile control if no command key was pressed. The work 

station user may have already made an entry on a display while the previous 

display is being processed because UNLOCK was specified for SUBCTL. If the 

work station user is still keying in data, the program waits for input. If the 

work station user has already pressed a command key or the Enter key, the 

work station device locks the keyboard and waits for the read request from the 

program. 


When CF3 (end of batch) is pressed, the program accesses the batch header. 
if the batch header has been deleted, the program terminates and the halt 
indicator H5 is on. If the batch header is accessed successfully, its status code 
is updated to reflect the batch header’s current status. 


When CF6 (review) is pressed, the transaction key (which is the key fields 
BATNUM and LSTNUM) is used to retrieve the last transaction record. If there 
iS no transaction record, the following message is displayed: 


No records exist for this batch 
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Figure 10-8. Output Specifications for MLG105 Transaction Data Entry Program 
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APPLYING TRANSACTION BATCHES TO MASTER FILE 


The batches of transactions in the transaction file are applied to the master file 
when a maintenance program is called. The maintenance program could be 
similar to the MLG311 program described in Chapter 7. In this case, however, 
a batch of transactions will be processed by the maintenance program only if 
the header record in the MLGHDRP batch header file indicates a batch status 
(BATSTS) of 3 (see Batch Header Record in this chapter). 
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PROGRAMMING CONSIDERATIONS 


« No validity checking occurs during MLG105. This program is used for batch 2 
input and allows transactions to be entered efficiently. If there are any 
errors in the input, they are detected by the maintenance program that 
applies transactions to a master file. 


« In addition to an application that has data entry, a batch header can be used 
in applications that do the following: 
— Edit 

Allow the work station user to correct invalid transactions 

Automatically update after a successful edit 


Various status codes can specify the status of each batch. 


»« |n the approach discussed in this section, multiple work station users add 
records to the same file. The batch number separates the different batches 
in the file. Using one file with key fields to separate the logical groups is 
preferable to having a file or member for each batch, because it reduces 
overhead in the system. 


Also in this approach, the batch header record was released at various points 
to remove the lock held by the program. When a file is coded as an update 
type, the system automatically locks the record until the update is performed or 
the lock is released. The lock prevents other users from retrieving the same 
record for update. Because of this, it is normally a good programming practice 
to retain locks for only a brief period of time in a data base system. Therefore, 
the batch header record was either updated immediately or the lock was 
released by doing an update by use of exception output with no fields being 
changed. Releasing a lock in the manner shown in the approach is more 
efficient than updating the record. If a request for a new batch is in error 
because the batch number already exists, a release of the existing header 
record occurs. 
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RECOVERY CONSIDERATIONS 


If incorrect data has been entered for a transaction, the entire transaction 
should be reentered with correct data. 


If there is a system failure while a work station user is doing key entry work, 
two ways to recover are: 


¢ To specify a value of 1 for the force write ratio (FRCRATIO) parameter when 
creating the physical file for the batch header records; and to use the FEOD 
(force end of data) operation on the transaction file, MLGENTL, just before 
the batch header’s status is updated (for completion). This will force the 
records to nonvolatile (auxiliary) storage. 


e To use data base logging on both the batch header file and the transaction 
file. Specify a value of 1 for the force write ratio parameter when creating 
the log file and execute a recovery program at the next IMPL (following a 
system failure) to synchronize the log file and the data base files. 


In either approach, the system operator does not need to determine who was 
using the system or help the work station users to restart. The work station 
users perform the recovery themselves in conjunction with the program design. 
Because the program provides for a specific work station user request to 
review the last transaction, the actual design and program code devoted to 
recovery is minimal. 


To allow for recovery from damaged objects (assuming you are keying in one 
or more batches of transactions per day), the transaction file could be saved 
every two to three days. If the damaged transaction file is not usable and the 
first recovery method described above is used, the backup can be restored. If 
the second recovery method described above is used, the transaction file can 
be rebuilt using the entries in the data base log. 
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Chapter 11. Interactive Maintenance from Multiple Work Stations 


OVERVIEW 


In Chapter 8, work station users interactively applied transactions to a master 
file through a DFU application. The more advanced approach in this chapter 
uses an RPG |II maintenance program in combination with a display file to 
provide a series of displays that allow work station users to interactively 
maintain a master file. This approach has the following characteristics: 


- A display file, MLG320D, formats four displays: PROMPT, CHANGE, 
ADDTN, DSPLY. 


e Work station users enter data on these displays to: 
— Add, change, delete, or review a record in the master file 


— Specify a title for the printed output report 


e An RPG III program, MLG320, applies work station input to a master file, 
MLGMSTP, through a logical files MLGMSTL. 


e Printed output occurs for any changes to the master file. 
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INTERACTIVE MAINTENANCE PROGRAM AND DISPLAY FILE 


An RPG program named MLG320 and a display file named MLG320D are 
created to allow work station users to display and modify the records in a 
master file. The work station user begins by calling MLG320, such as by 
selecting an option on a menu that calls the program (see the discussion of the 
program call menu and specialized user menus in Chapter 8). 


Program Flow 


A flowchart of the RPG III program is shown in Figure 11-1. This flow of the 
program centers around the entries made by the work station user. 











BEGIN 










PROMPT: 
For request 
type and 
account 
number 


Yes End 
of program 


No 


Chain to the 
mailing list 


master file 





Record No 
found 


wy 


Release 


the record 














PROMP: 


Yes 
Duplicate P net 
account eq 
number 
No 


Inquiry No Change Yes 
request request 


Yes No 










DSPLY: 


Inquiry request Delete Yes 
prompt request 
No 


From 
Part 2 


From 
Part 2 








PROMPT: 


Add No Invalid 
request account 
number 
Yes 











ADDTN: 
Add anew 
record 











Invalid 
state code 


Cancel Yes 
request 





Valid 
state abbrev, 


Yes Chain to 


mailing list 
file 








Part 2 Write (add) No Record 
anew master found 
record 

Yes 





Duplicate 
account 
number 








Part 2 Print the new 


master record 





Figure 11-1 (Part 1 of 2). Flowchart of MLG320 Maintenance Program 
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Figure 11-1 (Part 2 of 2). Flowchart of MLG320 Maintenance Program 
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(3 \ Part 1 
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The work station user begins by keying in a request type, account number, and 
report title on the following display, which is named PROMPT: 


MAILING LIST FILE MAINTENANCE-PROMPT CF1-End of program 


Request _ A = Add C= Change 0D = Delete I = Inquiry 


Account number 


Printer report notes 


The -Printer report notes- appear at the top of the printed output 





A record can be added to the master file, changed, reviewed (inquiry), or 
deleted from the master file. An existing or new account number can be 
entered. Text (such as date or batch number) can be entered for the Printer 
report notes. If CF1 (end of program) is pressed, the program returns. 


The program tests for a valid combination of entries. If an addition is 
requested, the account number cannot exist on the file. If change, delete, or 
inquiry is requested, the account number must exist. 


If the entries are not a valid combination, one of the following error messages 
appears on the PROMPT display: 


Duplicate account number 
Invalid account number 


The program branches to unique routines depending on the type of request. 


When a request is made to retrieve a record, that record becomes locked 
because the file is specified as update. Other work station users (or a batch 
program) who request that same record for a change or deletion cannot 
retrieve the record until the lock is released. (The programs can be coded with 
a time-out exception handling routine; however, this is not discussed in this 
publication.) To prevent a record from being locked to other users, the 
program releases the record. 
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The record is retrieved again if the work station user requests to change or 
delete it. When the record is retrieved, it may not be the same {another work 
station user may have changed it). If the record is not the same, one of the 
following error messages appears: 





Record was just deleted (on PROMPT display) 
Record has just been changed by someone else. Review request {on 
CHANGE display) 


The program displays these messages based on the value of the lock control 
field (MLGLK1) in the retrieved record. (MLGLK1 is a three-digit field and is 
shown in the field reference file MLGREFP in Chapter 6.) When a request is 
made from the PROMPT display to retrieve a record, the value in MLGLK1 is 
saved. When the record is retrieved again for the actual update, the value in 
MLGLK1 is compared with the saved MLGLK1 value. If the values are the 
same, the record has not been changed; however, if the values are not the 
same, the record has been changed because the value in MLGLK1 is 
incremented by 1 each time an update is made. This ensures that multiple 
work station users are notified when they are trying to update the same record 
at the same time. Because MLGLK1 is defined as a numeric field, its value is 
initialized at O. At the 1000th update, the field is automatically reset to O00. 


If a request to add a record is made, the PROMPT format is displayed and the 
work station user can enter a record or cancel the request. If a record is 
entered, the program checks whether or not the account number is still unique 
(another work station user may have just entered the same account number). If 
the account number is unique, the program adds the new record to the file and 
prints the record on the printer output report, as shown below: 





9/21/31 MATLING LIST MAINTENANCE PAGE 1 


ACCT TYP NAME ACDRESS CITY STATE ZIP COMMENT 


12300 % PM DAVIS 1320 SOUTH ROD PITTSBURGH PA 15238 ADDED 





lf a request to change a record is made, the data from the master record fields 
is moved to the change fields (KNAME, XADDR, XCITY, XSTATE, XZIP, 
XACTTYP) and the value of MLGLK1 is saved. The CHANGE format is 


C displayed: 


MAILING LIST FILE MAINTENANCE-CHANGE REQUEST ENTER-Change record 


CF7-Cancel request 


Account number 12345 


Name 
Address 
City 
State 


Zip 


WA SMITH 

500 MAIN ST 

LOS ANGELES 
CA 


90045 


Type of account 





The request can be canceled (press CF7) or the record can be changed (press 
Enter). If Enter is pressed, the master record is retrieved again and the value 


same: 


of MLGLK1 is compared with the saved MLGLK1 value. If the values are the 


« The existing master record is printed on the printer output report (as shown 


below). 


e The change fields are moved to replace the existing master fields. 


« MLGLK1 is incremented by 1. 


e« The master record is updated. 


e The new master record is printed on the printer output report (as shown 


below). 


9/21/81 


ACCT TYP NAME 


12345 1 w A SMITH 
12345 1 w A SMITH 


C 


MAILING LIST MAINTENANCE PAGE 1 
ANDRESS CITY STATE ZIP COMMENT 
500 MAIN ST LOS ANGELES CA 90045 BEFORE 
320 PACIFIC AVE SAN JOSE CA 95112 AFTER 
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If a request to delete a record is made, the value in MLGLK1 is saved and a 
copy of the master record is displayed in the DSPLY format: 





MAILING LIST FILE MAINTENANCE-DELETION REQUEST CF5-Confirm deletion 
CF7-Cancel request 


Account number 12345 
Name WA SMITH 


Address 500 MAIN ST 


City LOS ANGELES 


State CA 
Zip 90045 


Type of account 1 





The request can be confirmed (press CF5) or canceled (press CF7). If it is 
confirmed, the master record is retrieved and the value of MLGLK1 is checked. 
lf the value of MLGLK1 has not changed, the master record Is printed and then ) 





deleted. If the work station user presses a command key other than CF5 or 
CF7, an error message is displayed. 





If a request to inquire into a record is made, the DSPLY format is displayed: 


MAILING LIST FILE MAINTENANCE-INQUIRY REQUEST ENTER-Return 


Account number 12345 


Name 
Address 
City 
State 


Zip 


WA SMITH 


500 MAIN ST 


LOS ANGELES 


CA 


90045 


Type of account 1 





The master record is displayed. The work station user presses Enter (which is 
the only valid key) to return to the PROMPT display. 


Data Description Specifications for MLG320D 


The DDS for MLG320D are shown in Figure 11-2. These DDS could be 
generated using the screen design aid, which was introduced in Chapter 8 and 
is described in detail in the SODA Reference Manual and User’s Guide. 
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Figure 11-2 (Part 4 of 4). DDS for MLG320D Display File 


The REF keyword specifies that the field reference file MLGREFP is to be used. 


The name PROMPT specifies the format for the first prompt, which requests 
the type of work to be done. The fields REQST and ACTNUM are input fields. 
The keyword ERRMSG specifies the error conditions that are determined by 
the program. The fields PRVACT and PRVNAM are output fields. These two 
fields are conditioned to properly describe the last function specified. This 
feedback is to assist the work station user. The SETOFF keywords are used to 
ensure that the values are not displayed again. The field PRTHDG is an |/O 
field. 


The name CHANGE specifies the format for the prompt which allows a record 
to be changed. CF7 is the cancel command key, which cancels the request. 
The fields into which changes are entered have names different from those in 
the master record. This is because the master record is released and retrieved 
again after changes have been entered. The B in position 38 specifies that 
those fields contain data that can be both displayed and changed. 
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The name ADDTN specifies the format of the prompt that allows you to add a 
record. The request can be canceled by pressing CF7. The | in position 38 
specifies all fields as input fields. 





The name DSPLY specifies the format for the prompts that allow delete and 
inquiry. CF7 (cancel request) and CF5 (delete request) are valid only if a delete 
request is made. Because position 38 is blank for each field, these fields are 
output fields and the data in them cannot be changed by the work station user. 
The constant CF5-Confirm Deletion is always on the delete display, but it will 
appear in high intensity when an error occurs. The following are possible error 
conditions: 


¢ A command key, which is required on a delete request, is not pressed. The 
work station user must press a command key and not the Enter key. 


e A delete occurs and the value in MLGLK1 is changed. It is probably an 
Operational error to delete that record. 


RPG II! Specifications for MLG320 


The RPG Ill specifications for the mailing list maintenance program MLG320 
are shown in Figures 11-3 through 11-5. A description of the new RPG III 
operation codes—DO, IF, ELSE, END-—follows. 


The DO statement is a convenient form to group statements that must be 
performed under the same condition. The DO statement may be conditioned 
as it is in statement @ (Figure 11-4, part 1). The END statement ends the DO 


group. 





The IF statement may be used to test a condition and perform a series of 
statements. In statement © (Figure 11-4, part 3), the IFEQ operation is used 
to test indicator 97 for an on condition (the value 1 is on and 0 is off). *IN97 is 
the field name for indicator 97. 


In statement @ (Figure 11-4, part 3), the IFEQ operation is used to test 
indicator 95 for an off condition. The ELSE operation in statement @ (Figure 
11-4, part 3), is used to begin a series of statements that are executed if 
indicator 95 is on. 


In statement rE (Figure 11-4, part 3), another DO operation is nested within 
the previous IF statement. The term nested means that the statements are a 
subgroup of the previous group. The nested DO group ends on statement @ 
(Figure 11-4, part 3). The ELSE statement ends on statement @ (Figure 11-4, 
part 3). The RPG III compiler will print a nest level number on each statement 
to assist you in determining where a level begins and ends. 
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Figure 11-3. Control and File Description Specifications for MLG320 Maintenance Program 
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Figure 11-4 (Part 3 of 4). Calculation Specifications for MLG320 Maintenance Program 
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Figure 11-4 (Part 4 of 4). Calculation Specifications for MLG320 Maintenance Program 


This program specifies three files: 
e MLG320D - a work station file 
« MLGMSTL - a data base file 

e QPRINT - a print file 


The program causes data to be processed as described under Program Flow in 
this chapter. 


The statement EXFMT (execute format) is followed by a test for an 
end-of-program request. If requested, LR is set on and the program returns 
(RETRN)}. 

The ACTNUM field and the request entered by the work station user are 
validated. If an error occurs, the PROMPT display is shown again. The master 


record is released immediately. 


The program branches to one of the following four routines, depending on the 
work station user's request. 


The INQUIRY ONLY routine is an inquiry that branches to the PROMPT display. 
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The CHANGE DISPLAY routine moves a copy of the master record fields to the 
change fields so the data in these fields can be changed. The CHANGE format 
is displayed and the program recognizes the following situations: 


« The work station user wants to cancel the request. 
« The record was deleted since the request to change it was made. 
e The value of MLGLK1 has changed. 


When a change is to be made, the existing master record is printed, the 
changed fields replace the existing fields, the value of MLGLK1 is incremented, 
the master record is updated (EXCPT UPDHDR)}, and the changed master 
record is printed (EXSR PRINT). 


The DELETE RECORD routine saves the value of MLGLK1 and displays the 
record to be deleted (EXFMT DSPLY). The program recognizes the following 
Situations: 


« The work station user wants to cancel the request. 

« The record has just been deleted by someone else. 

« CF5 or CF/ was not pressed. 

DELET MLGMST deletes the record. No program can access the record. 


The ADD NEW RECORD routine displays the ADDTN format (EXFMT ADDTN) 
and recognizes the following situations: 


« The work station user wants to cancel the request. 
e The account number has just been used by someone else. 


When an addition is to be made, the new record is added to the file (WRITE 
MLGMSTR) and printed (EXSR PRINT). Because the WRITE statement writes 
all fields for the file, output specifications arc not needed. 


The PRINT routine does printing by exception time output (E in position 15). 
The print file is opened the first time printing is requested. Printed output does 
not occur if the program is used for inquiry only. The report title is printed the 
first time the routine is used. Indicator 56 is set on to prevent the print file 
from being opened again and the report title from being printed. The detail line 
is printed (EXCPT DETAIL), and overflow is checked. (Because all printing is 
done through exception output, the normal RPG III cycle control cannot be 
used for either heading or overflow.) If there is overflow, the heading is 
printed. 








=~ 


C 


The output specifications have two records for the MLGMSTR record. The first 
(RLSHDR) is one with no fields specified. This releases the lock on the record 
so that other jobs on the system can request an update to the same record. 
This method of releasing the lock is more efficient than updating the record 
with the same information. The other record (UPDHDR) does the update for a 


changed condition. 


The output to print the heading lines and the record is in the QPRINT file. 
Conditioned constants on the record specify the type of record being printed. 


The output specifications in Figure 11-5 specify the layout of the printer 


output. 
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Figure 11-5 (Part 1 of 2). Output Specifications for MLG320 Maintenance Program 
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Figure 11-5 (Part 2 of 2). Output Specifications for MLG320 Maintenance Program 
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ALTERNATIVE SOLUTION FOR THIS APPLICATION APPROACH 


In this application approach, the technique of using change fields (for example, 
XNAME) was used to hold the new values while the master record containing 
the disk record fields (for example, NAME) was reaccessed. The purpose of 
reaccessing the master record was to avoid a locked record condition while the 
work station user made a decision. If the same field names are used, 
reaccessing the disk record after reading the changes from the display will 
cause the field values from the disk record to overlay the changed values from 
the work station user so that the changes would be lost. This situation is 
similar to other maintenance programs in this publication where different 
names are used for the change fields. 


It is possible to use the same field names and not lock the master record 
during the user decision time by using a DDS option and minor additional 
coding. The major advantage of using the same names is to reduce the 
maintenance considerations of adding new fields to the master record. For 
example, in the program as shown, if a new field is added to the master record 
that must be maintained in this program, the new field must be described in 
multiple places within the program. 


An alternative solution is to use the DDS keyword RTNDTA. This allows the 
data from the work station to be reread from the main storage buffer after 
accessing the master record. Without the DDS keyword, the data would be 
read from the work station again. This can cause confusion to the operator 
and also causes a loss of performance. The DDS keyword RTNDTA allows a 
simple form of rereading the same data. 


The basic steps in the sequence of events for a CHANGE request were coded 
as: 


1. | EXFMT the PROMPT format 

2. For a CHANGE request, CHAIN to the master record 

3. Release the lock on the record 

4. Save the lock control field 

5. Move the master fields to change fields 

6. | EXFMT the CHANGE format 

7. CHAIN to the master record 

8. Move the change fields to the master field 

9. Update the master 

With the RTNDTA keyword approach, Step 5 could be removed. Instead of 


the current Step 8, a READ to the CHANGE format would be used. This would 
overlay the master fields that were reset by the CHAIN statement in Step 7. 
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RECOVERY CONSIDERATIONS 


If incorrect data has been entered for a transaction, the RPG maintenance 
program MLG320 can be executed again to change the incorrect data. 


If there is a system failure while the work station user is entering transactions, 
one of the following approaches could be used: 


e When the master file MLGMSTP is created by the Create Physical File 
(CRTPF) command, there is a parameter named force write ratio 
{(FRCRATIO) to control the frequency in which records are written to 
auxiliary storage. Using the default for this parameter provides the best 
performance. If the default (*NONE) is used, the work station users should 
check the last several transactions they entered to ensure they were 
recorded in auxiliary storage. 


The system may not write the records to auxiliary storage in the same 
sequence in which the updates occurred. All of the transactions entered 
may not be reflected because some records may have been in main storage 
at the time the system failure occurred and cannot be recovered. 


The listing that is printed upon the exit from the application may be used to 
determine what transactions were entered. The transactions will be listed in 
the correct sequence, but the listing may not be completely up-to-date. 
Printed records are spooled and are kept in buffers in main storage; 
therefore, some records may be lost if a system failure occurs. 


» If the force write ratio parameter value is specified as 1, the work station 
users should look at their last entry to determine if it exists before 
continuing. In this situation, the printed listing may not be as up-to-date as 
the data base. 


e Use data base logging where the log file has a force ratio of 1. Synchronize 
the data base log and the data base file after a system failure. 


To recover from damaged objects, two approaches are: 

e Reenter the transactions entered since the last backup was made. 

e Use data base logging to log the changes to the file. The master file can be 
backed up periodically. The data base log can be backed up daily (more 


frequently if desired). To recover the file, restore the backup and execute a 
special recovery program to reapply the log entries. 
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Appendix A. An Approach to Using Libraries 


System/38 supports multiple libraries, which allow you to organize your work 
so that your application is easy to use. 


When designing an application, you need to consider many requirements, such 
as production operations, program development, backup, security, and operator 
training. The approach to using libraries presented in this appendix considers 
these requirements in a mailing list application. This appendix will: 


e« Describe multiple mailing list libraries and their purpose 
e Show how to create these libraries 


e Show how to use these libraries 


MAILING LIST LIBRARIES AND THEIR PURPOSE 


There are two groups of mailing list libraries, each with a different owner (a 
user with a unique user profile). These two owners are: 


« Development programmer (DEVPGMR) 
« Administrative programmer (ADMPGMR) 


The development programmer does the initial program development and 
program maintenance. To help protect against unintentionally modifying 
production data, the development programmer is not authorized to create or 
delete objects in the production library. 


The administrative programmer controls the production system. He does very 
little actual programming. He copies the source code created or changed by 
the development programmer and creates or re-creates that code for the 
production system. 


While this approach may appear cumbersome and requires additional auxiliary 
storage and program compilations, it does provide a basis for better control 
than a single library and a single programmer. From a system management 
point of view, it may be highly desirable to control changes to the production 
system. 
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The mailing list libraries, their owners, and their purposes are summarized 


Purpose 


Program development 


and maintenance objects 


Build library for 


production programs 


Production programs 


and display files 


Production data that 


is infrequently saved 


below: 
Library Owner 
MLGLIBDEV DEVPGMR 
MLGLIBBLD ADMPGMR 
MLGLIBPGM ADMPGMR 
MLGLIBOP ADMPGMR 
MLGLIBOP1 ADMPGMR 


Production data that 


is frequently saved 


The relationship of these libraries is indicated in Figure A-1. 
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Figure A-1. The Mailing List Libraries and Their Owners 
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The discussion that follows describes these libraries and their objects in more 


detail. 





( 
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MLGLIBDEV is used for program development, testing, and maintenance. It is 
created as a test library to allow the default use of the Enter Debug Mode 
(ENTDBG) command to permit the updating of files within this library. This 
library contains the following objects: 


¢« Source files-QCLSRC, QDDSSRC, QRPGSRC, QUDSSRC; these source files 
are created for testing such that only the development programmer can 
update them. The source files would be created in a manner similar to that 
described in Chapter 6. The authority to use the files would then be 
changed so that only the development programmer can update them. This 
would be done by using commands such as: 


RVKOBJAUT QCLSRC.MLGLIBDEV OBJTYPE(*FILE) USER(*PUBLIC) 
AUT(*ADD *DLT *UPD) 


e Physical files—-contain test data. 

e Logical files—used to access the test data in physical files. 

¢ Set library list program—contains the RPLLIBL command for the following 
libraries: MLGLIBDEV, MLGLIBPGM, QGPL, QTEMP, QIDU, QRPG. If the 
reformat utility is needed in the application, QS3E would be added at the 
end of the list. The program would be created in a manner similar to that 
described in Chapter 6. 

e Job description—contains the same library list as the replace library list 
program. The job description would be created in a manner similar to that 
described in Chapter 6. 

e Job description data area—contains the name of the job description; allows 
CL programs that require a job description to be written independently of the 
library that contains the CL program (for more information on this concept, 
see Appendix B). 


The data area would be created by the following command: 


CRTDTAARA JOBDTAARA.MLGLIBDEV TYPE(*CHAR) 
LEN(10) VALUE(MLGLIBDEV) 


e Programs-—test versions of the production programs. 


¢« Display files-test copies of the production files. 
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MLGLIBBLD contains source files and serves as a staging area for creating 
objects. This library is authorized such that only the administrative programmer 
can add objects. It contains the following: 


¢« Source files-QCLSRC, QDDSSRC, QRPGSRC, QUDSSRC; these source files 
are created such that only the adminstrative programmer can update them. 


e Set library list program—contains the RPLLIBL command for the following 
libraries: MLGLIBBLD, MLGLIBPGM, MLGLIBOP, MLGLIBOP1, QGPL, 
QTEMP, QIDU, QRPG. If the reformat utility is needed in the application, 
QSE3 would be added at the end of the list. 


e Job description—contains the same library list as the set library list program. 

e Job description data area—contains the name of the job description; allows 
CL programs requiring a job description to be written independently of the 
library that contains the CL program. 

e QObjects—all objects are created in this library and then moved to one of the 


three production libraries (MLGLIBPGM, MLGLIBOP1, MLGLIBOP). 


MLGLIBPGM contains the production programs and files needed for this 
approach to the mailing list application. This library is created such that only 
the administrative programmer can add objects. It contains the following: 


e« Source files-QCLSRC, QDDSSRC, QRPGSRC, QUDSSRC; these source files 
are created such that only the administrative programmer can update them. 


e Programs—used to process the production data. 


e Display files—for the program. 





‘MLGLIBOP contains production objects infrequently saved. It is created such 
that only the administrative programmer can add objects and contains the 
following: 

e« Physical files—infrequently saved. 

e Logical files-used to access the production data. 

e Set library list program—contains the RPLLIBL command for the following 
libraries: MLGLIBPGM, MLGLIBOP, MLGLIBOP1, QGPL, QTEMP, QIDU, 
ORPG. lf the reformat utility is needed in the application, QS3E would be 
added at the end of the list. 


e Job description—contains the same library list as the set library list program 
and is used for batch jobs. 


e Job description data area. 
« Data areas—infrequently saved; communicates data, such as CL variable 


values, between the programs. 


MLGLIBOP1 contains production objects frequently saved. It is created such 
that only the administrative programmer can add objects and contains the 
following: 


e Physical files. 


e Data areas. 
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USING THE MAILING LIST LIBRARIES 





The intent of the following discussion is to show how the development 
programmer and administrative programmer interact as owners of various 
libraries within the same application. 


Sign-On for Development Programmer 


The development programmer signs On using a unique password. The library 
list is created by calling the set library list program in the library MLGLIBDEV. 
Using the programmer menu, the compilations are submitted to batch with a 
unique job description. Defaults are generally used on all create commands. 
Consequently, when creating a logical file, the maintenance default of 
immediate is used during the test phase, even though that logical file may be 
designed for rebuild maintenance. This simplifies testing by eliminating 
repetitive specifications each time an object is re-created. 


The development programmer could be prevented from adding objects to 
QGPL (assuming that all of his objects are in one library, MLGLIBDEV) by 
removing the public authority to add to QGPL. Removing the public authority 
to the QBATCH job description will assist the development programmer in 
specifying the correct entries on the programmer menu. 


Program Development and Maintenance 


When the development programmer needs to develop programs or update J 
certain objects, the production programs and production display files can be 

used, along with a test version of any object that is being changed. The 

production data in MLGLIBOP and MLGLIBOP1 should not be used. 





Sign-On for the Administrative Programmer 


The administrative programmer signs on using a unique password. The library 
list is created by calling the set library list program in the library MLGLIBBLD. 
This library is owned by the administrative programmer and is not used by the 
other production library users. 





Placing Objects into Production Libraries 


After the development programmer has created the source for the application, 
a transmittal form is prepared for the administrative programmer. This 
transmittal form could be either informal or formal. The administrative 
programmer then copies the source into his library, MLGLIBBLD, and recreates 
the objects in this library. Options on create commands, such as 
MAINT(*REBLD) or TEXT description, are specified at this time. 


After the administrative programmer has satisfied himself that the object is 
correct, he moves it to the appropriate production library depending upon 
object type and backup requirements. If an object already exists in a 
production library, it must be deleted prior to moving the new version of the 
object. The production source is then copied to the source file in MLGLIBPGM 
to serve as the official source for the production system. 


If a data file is being replaced, the new version is created in MLGLIBBLD. The 
Copy File (CPYF) command can then be used to copy any data from the old 
version to the new version. The old version is then deleted and the new 
version moved to the appropriate library. 


The library MLGLIBBLD allows the administrative programmer to assemble all 
the objects necessary so they may be placed into a production library at the 
same time. When the objects are actually moved to the production library, the 
users of the production library must not be using the objects that are being 
moved. By successfully compiling all of the objects into MLGLIBBLD, the 
administrative programmer can minimize the time when the users of the 
production library cannot use the production objects and the number of times 
an incorrect change makes the production system inoperable. 


Critical Applications 


When critical applications are being updated, the changes could be made first 
to a training library. This library would contain duplicates of the important 
objects. In this way, the work station users can be trained and the programs 
can be tested at the same time without unintentionally changing the production 
data. 
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Sign-On for the Users of the Production System 


The set library list program is called when the work station user signs on and J 
requests a function from the production system. This program is placed in 

MLGLIBOP, instead of in MLGLIBPGM, to protect against unintentional 

changes which may be made by the development programmer if he can 

execute programs in MLGLIBPGM. 


Online Backup 


Online backup is internally copying a file using the CPYF or CPYF| command. 
To allow normal recovery, the file should not be changed while it is being 
copied. 


Online backup allows: 
« Faster backup and recovery operations. 


« The copy of the data base to be saved offline at any time without impacting 
the production system. 


« Less frequent offline saving of objects (depending upon the recovery 
requirements). 


To provide online backup in an unattended environment, a batch program is 

run using the job description in library MLGLIBOP. The specified files and data . 
areas in MLGLIBOP'1 are copied to a user-created system-wide backup library 2 
or an application-oriented library. To do this, the Copy File (CPYF) command is 

used with the COMPRESS(*NO) parameter to provide a high-speed copy 

function. A data area object cannot be copied, but the contents of a data area 

object may be read from one library and written to another. The backup library 

should be saved frequently. 


PROGRAMMING CONSIDERATIONS 


In some applications it would be easier and provide better control if the 
development programmer has a unique set of objects and does not have library 
MLGLIBPGM on his library list. This approach would cause additional auxiliary 
storage requirements for the system, but a simpler concept is the result. 





Appendix B. Using Menus 


In many applications, you may want to create menus that are appropriate and 
time-saving for your application. This appendix discusses the following two 
uses for menus: 


« A series of menus 


e Batch jobs submitted from a menu 


A SERIES OF MENUS 


In some applications, you may want to provide various task options on a menu 
for the work station user. You can do this by creating a series of menus. For 
example, the work station user who updates the mailing list may also need to 
update accounts payable. All task options for the mailing list application and 
the accounts payable application could be on one menu; however, dividing the 
options by application makes the tasks easier to understand and use, and 
makes the applications more flexible. 


A sample series of menus is shown here: 


INITIAL MENU 
Select one of the following: 
1. Mailing list application 
2. Accounts payable application 
90. Sign off 


Option: 






ACCOUNTS PAYABLE MENU 
Select one of the following: 

1. (option) 

2. loption) 
60. Return 
90. Sign off 










Option: __ 


MAILING LIST CLERK MENU 
Select. one of the following: 

1. Enter transactions 

2. Submit batch maintenance program 
60. Return 
90. Sign off 








Option: __ 


Using Menus B-1 


The initial menu is similar to the menu created in Chapter 8. Each option 
causes a CALL command in a CL program, such as the following, to be 
executed: 


IF (&RESP *EQ 1) CALL MLGOO5C.MLGLIBOP 
IF (@ RESP *EQ 2) CALL APYOO8C.APYLIBOP 


Note that a qualified name is used to call the program. The program, 
MLGOOD5SC, replaces the library list for the mailing list application and invokes 
the mailing list clerk menu program. 


The menus that follow the initial menu each have several options relating to 
that specific application, a sign-off option, and a return option. The return 
option causes the previous menu to appear again. (There is no return option 
on the initial menu because this is the first menu to appear.) The return option 
is coded as follows: 


IF (RESP *EQ 80) RETURN 


The Return (RETURN) command in a CL program ends the program and 
returns to the previous program. 
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BATCH JOBS SUBMITTED FROM A MENU 


The work station user often can determine when a batch job should be 
submitted. For example, a work station user enters a batch of transactions and 
wants the batch maintenance program executed. He can do this without the 
assistance of the system operator by selecting an option on a menu like the 
one shown here: 


MAILING LIST CLERK MENU 
Select one of the following: 
1. Enter transactions 
2. Submit batch maintenance program 
80. Return 
90. Sign off 


Option: __ 





lf the work station user selects option 1, he can enter data into a transaction 
file using the DFU application MLG110U (which was discussed in Chapter 7). 


If the work station user selects option 2, he submits a job to update the 


master file using the RPG III program MLG311 (which was discussed in 
Chapter 7). 


Using Menus’ B-3 


The DDS for the display file that creates this menu are shown in Figure B-1. 
The display file is named MLGO36CD. 
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Figure B-1. DDS for MLGO36CD Display File 
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This display file is similar to MLGO35CD. If indicator 51 is set on, an * on the 
display is highlighted and blinks. This tells the work station user that his input 
has been accepted. Your application should have some type of feedback 
(message or intervening display) so that the work station user does not try to 
submit his input again and cause multiple batch jobs to be submitted for the 
same function. 


The SETOFF keyword specifies that the indicator is to be set off each time a 
response is sent to the program. The display device data management does 
not set off the indicator until the option indicators to define the display format 
are used. Because SETOFF is a record level keyword, it must be specified 
before the options in the DDS. 


If option 80 is selected, the previous menu returns as described under A Series 
of Menus earlier in this appendix. 


CL Program with Commands Using Fixed Values 


The CL program to execute the options on the mailing list clerk menu is named 
MLGO36C and is similar to MLGO35C (which was discussed in Chapter 8). The 
code for MLGO36C follows: 


PGM /* MLGO36C MAILING CLERK MENU “*/ 
DCLF MLGO36CD 
BEGIN: SNDRCVF RCDFMT (MENU) 

IF (RESP *EQ 1) CHGDTA APP(MLG110U)/* ENTER + 
TRANSACTIONS “/ 

IF (®RESP *EQ 2) + 
DO /* SUBMIT MAINTENANCE */ 
SBMJOB JOB (MLGMAINT) JOBD(MLGLIBDEV) ROQSDTA(’CALL MLG311’) 
CHGVAR &IN51 ‘1’ /* SET FOR RESPONSE CONSTANT */ 
ENDO 

IF (®RESP *EQ 80) RETURN 

IF (&®RESP *EQ 90) SIGNOFF 

GOTO BEGIN 

ENDPGM 
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If the work station user selects option 2, a DO group starts. All the commands 
between DO and ENDDO are executed at this time. Within the DO group is a 
Submit Job (SBMJOB) and a Change Variable (CHGVAR) command. SBMJOB 
places a job containing request data (which is normally a CL command) on a 
job queue. The JOB parameter specifies a name for the batch job, which is 
MLGMAINT. The JOBD parameter specifies the name of the job description, 
which is MLGLIBDEV (this is the same job description you used to submit 
batch compilations in Chapters 6, 7, and 8). The ROSDTA parameter specifies 
the command that is to be executed, which is CALL MLG311. That command 
and its parameter are enclosed in apostrophes. The ROSDTA parameter 
accepts only a single value (as opposed to a list of values) that can be either a 
variable or a character string. In this case, the apostrophes define the 
character string. The request to call MLG311 is the same command that was 
submitted from the programmer menu in Chapter 7. In that example there is a 
discussion of the work station user submitting a CL program that includes the 
call to the maintenance program, a Copy File (CPYF) command to permit the 
backup of all transaction batches, and a Clear Physical File Member (CLRPFM) 
command. This approach could be used instead of invoking the RPG IIl 
program MLG311. 


The Change Variable (CHGVAR) command sets on indicator 51 by assigning 
the variable &IN51 a value of 1. &IN51 is the name used for indicator 51 in 
the display file. The indicators listed in the display file are automatically 
declared to the program by the Declare File (DCLF) command the same way 
the &RESP field is declared (see Creating the Control Language Program 


MLGO35C in Chapter 8). When indicator 51 is on, the following message appears: 


* Batch job submitted for option 2 











Using a Data Area for a Job Description 


In the previous example, the JOBD parameter value of the SBMJOB command 
is MLGLIBDEV. This means the same program could not be used for both 
development and production. To allow joint use, a data area can be 
established in each of the environments that contains the name of the job 
description to be used. This approach was described in Appendix A. 


Assume that a data area exists in each environment (as described in Appendix 
A) by the name of JOBDDTAARA. The CL program executing the SBMJOB 
command would include: 


DCLDTAARA JOBDDTAARA 

RCVDTAARA JOBDDTAARA 

SBMJOB JOB(MLGPRINT) JOBD(&®JOBDDTAARA) ROSDTA('CALL MLG311') 
Note that the name of the data area is specified as an object name (no &) in 
the Declare Data Area (DCLDTAARA) and Receive Data Area (RCVDTAARA) 
commands and as a variable (preceded by &) when the name is specified for 
the JOBD parameter. The object name (no &) is used when the object itself is 
specified. 


At the time the program ts created, the data area is accessed to determine its 
attributes similarly to the way an externally described data file is accessed to 
determine its attributes. Because a qualified name was not used, the program 
will use a data area named JOBDDTAARA through the library list. Depending 
upon how the library list is established, the program will access a different 
value. Assume the library structure described in Appendix A is used. In this 
situation, the value accessed will be MLGLIBDEV for the development library or 
MLGLIBOP from the production libraries. The RCVDTAARA command retrieves 
the actual value from the data area and places it in the CL program. The 
submitted job will now use the same library list that was used by the 
interactive program. 


Another alternative is to use the same name for the job descriptions (such as 


MLGLIB) in both library lists. This would allow the program to use a constant 
name instead of extracting the name from a data area. 
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Using a Single Variable Character Value 


In the previous section (CL Program with Commands Using Fixed Values), the 
Submit Job (SBMJOB) command submitted a job with the same command; 
that is SBMJOB always submitted a job with the command CALL MLG311. 
This type of command is appropriate when the work station user enters a fixed 
value for a response (in this case, option 2). If the menu prompts the work 
station user to key in a variable entry, such as a file name, an override 
command must be used. An example of this type of menu and the DDS for 
this part of the menu are shown in Figure B-2. 
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Figure B-2. Menu and DDS for a Variable Command Program 


The display file allows input to the variable named FILE. Because the display 
file is an externally described file, the variable named FILE will be automatically 
declared within the CL program. The variable name is changed to &FILE. The 
& is used within CL programs to distinguish variable names from constants. 
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Key parts of the CL program that creates the menu follow: 


DCL &CMD TYPE(*CHAR) LEN(100) 


CHGVAR &CMD VAR(’CALL MLGxxxC PARM(’ *CAT &FILE *CAT ’)’) 
SBMJOB JOB(MLGPRINT) JOBD(MLGLIBDEV) ROSDTA(&CMD) 


The CL program that executes as a result of a response to the menu follows: 


PGM PARM(&FILE) /* MLGxxxC */ 
DCL &FILE TYPE(*CHAR) LEN(10) 
OVRDBF MLGMSTP TOFILE(&FILE) 
CALL MLG615 

ENDPGM 


The CL program that displays the menu declares a variable named &CMD, 
which is a 100-character field. This variable becomes the command that is 
within the job that is submitted to the batch job queue. Note that a variable 
cannot be within the job that is submitted directly to the batch job queue; 
however, a character string can be within a job that is submitted to the batch 
job queue. 


The Change Variable (CHGVAR) command creates the command (that was 
within the job that is submitted to the batch job queue) by concatenating 
(*CAT) constants and a variable into a character string. For example, if FILEA 
is entered on the menu by the work station user, the CHGVAR command 
creates the following character string in the variable &CMD. 


CALL MLG615C PARM(FILEA) 


Note that quotes are used to define the constants, including the parentheses 
that surround the variable. The VAR keyword uses the outermost parentheses 
to define the limits of the character string. 


The CL program to be executed as a result of a response to the menu is 
submitted for processing within a batch job. It accepts a parameter variable, 
&FILE, which must also be declared to the program. &FILE is used in the 
TOFILE keyword of the Override with Data Base File (OVRDBF) command 
(OVRDBEF is discussed under Mailing List Program in Chapter 4). 
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CL Program with Commands Using Numeric and Character Values 


Multiple variable values can be passed to a CL program. These may include 
either or both character variables and numeric variables. 


Assume the work station user is prompted for both file name (for example, a 
character variable named FILE) and date (for example, a 6-digit numeric 
variable named DATEN). These values must be submitted as parameters to a 
batch program. The key parts of the CL program that submits the batch job 
are as follows: 


DCL &CMD TYPE(*CHAR) LEN(100) 
DCL &DATEA TYPE(*CHAR) LEN(6) 


CHGVAR &DATEA &DATEN 
CHGVAR &CMD VAR(’CALL MLGxxxC PARM(’ + 
*CAT &FILE *CAT‘’ *CAT &DATEN *CAT ‘)’) 
SBMJOB JOB(MLGPRINT) JOBD(MLGLIBDEV) ROQSDTA(&CMD) 


The DATEN and FILE variables would be declared in the display file. The 
&DATEA variable is declared in the program. 


The work station user would key the date into a 6-position numeric field 
(DATEN). Because the *CAT function only operates on character data, it is 
necessary to declare a character variable (@DATEA) and then move the numeric 
date to the alphabetic date variable. This is done by the CHGVAR command. 











The command to be submitted is then built up by use of the second CHGVAR 
command. Note that a blank position must be concatenated between the two 
variables so that they appear as separate parameters. The actual command 
that is submitted might look like: 


CALL MLGxxxC PARM(FILEA 100181) 
The CL program that executes in batch would be coded as follows: 


PGM PARM(&FILE &DATEN) 

DCL &FILE TYPE(*CHAR) LEN(10) 
DCL &DATEN TYPE(*DEC) LEN(15 5) 
OVRDBF MLGMSTP TOFILE(&FILE) 
CALL MLGxxx PARM(&DATEN) 
ENDPGM 


Note that a numeric variable (any value beginning with a digit is considered a 
numeric variable) is passed by the system with LEN(15 5) meaning 10 whole 
numbers and 5 decimal positions. Thus, the date would appear as 
0000100181.00000. The CL program must define this value as LEN(15 5) in 
order to receive the value correctly. 


In this example, the date is passed to an RPG program for further processing. 
The RPG program must define the field with the same definition as was 
passed. See the RPG II] Reference Manual and Programmer’s Guide for details 
on how to receive parameters. The system requirement of LEN(15 5) for 
numeric values is required only for the case where: 


¢ The program is called interactively. 
e The program is submitted to batch. 
If the CL program is called by another program, the actual definition such as 


LEN(6 O) could be used. See the CPF Programmer’s Guide for details on how 
to pass parameters. 
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Field 


ACTNUM 
ACTTYP 


ADDR 
BATDAT 
BATDSC 
BATNUM 
BATSTS 


CITY 
NAME 
STATE 
MLGLK1 
TRNNUM 
TRNTYP 


XACTNM 
XACTTP 


XADDR 
XCITY 
XNAME 
XSTATE 
XZIP 
ZIP 


Appendix C. Alphabetic Listing of the Field Reference File 


Length Decimal 
5 0 
1 0 

18 
6 0 
35 
6 0 
1 0 
18 
18 
2 
3 0 
5 0 
1 
5 0 
1 0 
18 
18 
18 
2 
5 0 
5 0 


Column Heading 


Account Number 


Acct Type 


Address 

Batch Date 
Batch Description 
Batch Number 


Batch Status 


City 

Name 

State 

Lock Control 
Transaction Number 


Trans Type 


Account Number 


Acct Type 


Address 
City 
Name 
State 

Zip Code 
Zip Code 


Text Description 


Account number 
Account type 


1 = business 

2 = government 
3 = organization 
4 = school 

5 = private 

9 = other 


Address 

Batch date 

Batch description 
Batch number 
Batch status 


1 = In process 
2 = to be continued 
3 = ready 


City 

Name 

State 

Control number used for record locking 
Transaction number 


Transaction type 


A = add 
C = change 
D = delete 


Account number 
Account type 


1 = business 

2 = government 
3 = organization 
4 = school 

5 = private 

9 = other 


Address 
City 
Name 
State 
Zip code 


Zip code 
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abnormal termination: System termination by a means 
other than the successful execution of the Power Down 
System (PWRDWNSYS) command. See also system 
termination. 


access path: The means by which CPF provides a 
logical organization to the data in a data base file so 
that the data can be processed by a program. See also 
arrival sequence access path and keyed sequence access 
path. 


activity level: An attribute of a storage pool or the 
system that specifies the maximum number of jobs that 
can execute concurrently in the storage pool or in the 
system. 


allocate: To assign a resource for use in performing a 
specific task. Contrast with deallocate. 


application: (1) A particular data processing task, such 
as an inventory control application or a payroll 
application. (2) In IDU, specialized program created by 
IDU from user input. An application is later called by 
DFU or the query utility. 


application program: A program used to perform a 
particular data processing task such as inventory control 
or payroll. 


arrival sequence access path: An access path that is 
based on the order in which records are stored in a 
physical file. Contrast with keyed sequence access path. 


attribute: A characteristic; for example, attributes of a 
field include its length and data type, and attributes of a 
job include its user name and job date. 


attribute character: A character associated with a field 
in a display file that defines how the field is displayed 
(such as underlined, blinking, or intensified). 


authority: The right to access objects, resources, or 
functions. 


authorization: The process of giving a user either 
complete or restricted access to an object, resource, or 
function. 


Glossary 


auto dup feature: In DFU, a function that duplicates 
certain types of information from predetermined fields in 
a previous record into the current record. 


auto report: A function of the RPG III licensed program 
that uses simplified specifications and standard RPG 
specifications to generate a complete RPG source 
program. 


auto report option specifications: An RPG coding 
form the programmer uses to specify options for an 
auto report program. 


autostart job: A job that is automatically initiated when 
a subsystem is started. 


auxiliary storage: All addressable storage other than 
main storage. Auxiliary storage is located in the 
system's nonremovable disk enclosures. 


basic working display: The display that serves as the 
base from which you make requests of the system at a 
work station. When the request is completed, you 
return to the display. It is usually the display you receive 
when you sign on. 


batch job: A group of processing actions submitted as 
a predefined series of actions to be performed with little 
Or no interaction between the user and the system. 


batch processing: A method of executing a program or 
a series of programs in which one or more records (a 
batch) is processed with little or no interaction with the 
user Or operator. Contrast with interactive processing. 


batch subsystem: A subsystem in which batch jobs are 
to be processed. IBM supplies one batch subsystem: 
QBATCH. 


branching: The technique of bypassing specific 
instructions or operations to alter the sequential 


execution of instructions in a program. 


branching instruction: An instruction that changes the 
sequence of program execution. 
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breakpoint: A place in a program (specified by a 
command or a condition) where the system halts 
execution and gives control to the work station user or 
to a specified program. 


breakpoint program: For a batch job, a user program 
that can be invoked when a breakpoint is reached. 


buffer: A portion of main storage into which data Is 
read or from which it is written. 


byte: A group of eight adjacent binary digits that 
represents one EBCDIC character. 


calculation specifications: An RPG coding form on 
which the programmer describes the processing to be 
done by the program. 


call: (1) To instruct that a program is to begin 
execution. (2) An instruction to a program to begin 
execution. (3) In data communications, the action 
necessary to make a connection between two stations 
on a switched line. 


central processing unit: Abbreviated CPU. See 
processor. 


CF key: See command function key. 


character: Any letter, digit, or other symbol in the data 
character set that is part of the organization, control, or 
representation of data. 


character field: An area that is reserved for a particular 
unit of information and that can contain any of the 
characters in the data character set. Contrast with 
numeric field. 


CL: See contro! language. 


class: An object that contains the execution parameters 
for a routing step. The system-recognized identifier for 
the object type is *CLS. 


close: A data manipulation function that ends the 
connection between a file and a program. Contrast with 
open. 


command: A statement used to request a function of 
the system. A command consists of the command 
name, which identifies the requested function, and 
parameters. 





command function key: At a work station, a keyboard J 
key that is used with the command (CMD) function 

control key to request preassigned functions. At the 

system console, a keyboard key, called a CF key, that is 

used to request preassigned functions. 


comment: A word or statement in a program, 
command, or file that serves as documentation instead 
of as instructions. A comment is ignored by a compiler. 


compile: To translate a source program into an 
executable program (an object). 


compile time: The time during which a source program 
is translated by a compiler into an executable program. 


compile-time array or table: An array or table in which 
the data is compiled with the source program and 
becomes a permanent part of the program. Contrast 
with execution-time array and preexecution-time array or 
table. 


compiler: A program that translates a source program 
into an executable program. 


compiler listing: A printout that is produced by 
compiling a program or creating a file and that optionally 
includes, for example, a line-by-line source listing, a 
cross-reference list, diagnostic information, and for 
programs, the description of externally described files. 





completion message: A message that conveys 
completion status of work. 


conditioning: (1) In a file, the use of indicators to 
control when certain functions or operations are to be 
performed. For example, in a display file, indicators can 
select fields to be displayed. (2) In an RPG program, the 
use of indicators to control when certain functions or 
operations are to be done. For example, in an RPG 
program indicators can control calculation or output 
operations. 


constant: Data that has an unchanging, predefined 
value to be used In processing. A constant does not 
change during the execution of a program, but the 
contents of a field or variable can. See also /iteral. 


constant field: In an externally described display or 
printer file, an unnamed field that contains actual data 
that is passed to the display or printer but is unknown 
to the program passing it. 





continuation lines: (1) Additional lines required to 
continue the coding of a CL command or a DDS 
keyword and its value. (2) In RPG, additional lines 
specified on the file description specifications to provide 
more information about the file being defined. 


control language: The set of all commands with which 
a user requests functions. Abbreviated CL. 


control language program: An executable object that 
is created from source consisting entirely of control 
language commands. 


control language variable: A program variable that is 
declared in a control language program and is available 
only to the program. 


Control Program Facility: The system support licensed 
program for System/38. It provides many functions that 
are fully integrated in the system such as work 
management, data base data management, job control, 
message handling, security, programming aids, and 
service. Abbreviated CPF. 


control specification: An RPG coding form on which 
the programmer provides information that affects 
program generation and execution. 


control statement: In RPG, entries on a control 
specification. 


controlling subsystem: An interactive subsystem that 
is started automatically when the system is started and 
through which the system operator controls the system. 
IBM supplies one controlling subsystem: QCTL. 


copy: The SEU operation in which records can be 
copied to a new location in a source member while the 
records are retained in their original location. 


CPF: See Control Program Facility. 
CPU: Central processing unit. See processor. 


create: (1) The function used to bring an object into 
existence in the system. (2) To bring an object into 
existence in the system. 


cursor: A movable spot of light, resembling a bright 
underscore, that shows where the next character will 
appear on the work station screen when a key on the 
keyboard is pressed. 


data area: An object that is used to communicate data 
such as CL variable values between the programs within 
a job and between jobs. The system-recognized 
identifier for the object type is *DTAARA. 


data base: The collection of all data base files stored in 
the system. 


data base file: An object that contains descriptions of 
how input data is to be presented to a program from 
internal storage and how output data is to be presented 
to internal storage from a program. See also physical 
file and logical file. 


data description specifications: A description of the 
users data base or device files that is entered into the 
system using a fixed-form syntax. The description is 
then used to create files. Abbreviated DDS. 


data file: Any nonsource file. A data file is created by 
the specification of FILETYPE(*DATA) on a create file 
command. 


data file utility: The utility of the Interactive Data Base 
Utilities licensed program that is used to create, 
maintain, and display records in a data base file. 
Abbreviated DFU. 


data type: An attribute used for defining data as 
numeric or character. 


DDS: See data description specifications. 


deallocate: To release a resource that is assigned to a 
specific task. Contrast with allocate. 


debug mode: An environment in which programs can 
be tested. 


default value: A value assumed when no value has 
been specified. 


delay maintenance: A method of maintaining keyed 
access paths for data base files. This method does not 
update an access path when the file is closed, but it 
retains updates in a delayed form so that they can be 
quickly applied at the next open, avoiding a complete 
rebuild. Contrast with rebuild maintenance and immediate 
maintenance. 
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delete: (1) To remove an object or a unit of data (such 

as character, a field, or a record). (2) The SEU operation 
tn which existing records can be removed from a source 
member. 


delimiter: A character or a sequence of contiguous 
characters that identifies the end of a string of 
characters. A delimiter separates a string of characters 
from the following string of characters. A delimiter is 
not part of the string of characters that it delimits. 


device file: An object that contains a description of 
how input data is to be presented to a program from an 
external device and/or how output data is to be 
presented to the external device from the program. 
External devices can be work stations, card devices, 
printers, diskette magazine drives, magazine tape drives, 
or a communications link. 


DFU: See data file utility. 
DFU application: See application. 
digit: Any of the numerals from O through 9. 


diskette file: A device file created by the user to 
Support a diskette device. 


diskette magazine drive: A diskette drive that can hold 
two magazines, each containing 10 diskettes, plus 
individual diskettes in three separate slots. It is used to 
transfer information between system internal storage 
and removable diskettes. 


display: A visual presentation of information on a work 
station screen, usually in a specific format. Display is 
often used as a shortened version of information 
display. 


display file: A device file created by the user to support 
a display work station or console. 


display format: The name of the device file and the 
name of the record format to be used when the 
subsystem obtains routing data from the user. 


display screen: An electronic display tube, similar to a 
TV picture tube, used to display information entered or 
received at the system console or a work station. 


display station: An input/output device containing a 
display screen and an attached keyboard that lets a user 
send information to or receive information from the 
system. 


do group: (1) A set of commands in a control language 
program delimited by a DO command and an ENDDO 
command that is conditionally executed as a group. (2) 
In RPG, a group of calculations that are executed one or 
more times based on the results of comparing factor 1 
and factor 2 of certain calculation operations (for 
example, DOUxx}). A DO operation and an END 
Operation are the delimiters for a do group. 


dump: To copy data in a readable format from main or 
auxiliary storage onto an external medium such as tape, 
diskette, or printer. 


edit: (1) To modify a numeric field to an external format 
by suppressing zeros and inserting commas, periods, 
currency symbols, the sign status, or other constant 
information. (2) The process of using SEU to key in new 
source records and update existing source records in a 
source member. 


edit code: A letter or number indicating what kind of 
editing should be done before a field is displayed or 
printed. 


edit display: The SEU display from which frequently 
performed operations, such as delete, copy, and insert, 
are requested. 


edit word: A user-defined word with a specific format 
that indicates how editing should be done. 


embedded blank: A blank that appears between 
characters. 


end position: In RPG, an entry in the output 
specifications that indicates where the end position of a 
field or constant is to be placed in the output record. 


enter: To press the Enter/Rec Adv key (on a work 
Station keyboard) or the Enter key (on the system 
console) or a command function key to transfer 
keyed-in information to the system for processing. See 
also key in. 


escape message: A message that can be monitored for 
and that describes a condition for which a program 
terminates without completing the requested function. 
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executable program: The set of machine language 
instructions that is the output from the compilation of a 
source program. The actual processing of data is done 
by the executable program. 


execute: To cause a program, command, utility, or 
other machine function to be performed. 


execution: The carrying out of the instructions of a 
computer program by a processing unit. 


execution time: The time during which the Instructions 
of a computer program are executed by a processing 
unit. 


execution-time array: |n RPG, an array that is loaded 
or created by input or calculation specifications after 
actual execution begins. Contrast with compile-time 
array or table and preexecution-time array or table. 


extension and line counter specifications: An RPG 
coding form on which the programmer provides 
information about record address files, arrays, and tables 
and their associated files used by a program and about 
the number of lines to be printed on the printer forms 
that are used. 


external message queue: A message queue that is 
part of the job message queue and is used to send 
messages between an interactive job and the work 
station user. For batch jobs, messages sent to the 
external message queue only appear in the job log. 


external storage: Data storage other than main or 
auxiliary storage. 


externally described data: Data contained in a file for 
wnich the fields in the records are described to CPF, by 
using data description specifications, when the file is 
created. The field descriptions can be used by the 
program when the file is processed. Contrast with 
program-described data. 


externally described file: A file for which the fields in 
the records are described to CPF, through data 
description specifications, when the file is created. The 
field descriptions can be used by the program when the 
file is processed. Contrast with program-described file. 


factor: In RPG, an entry (for example, a field name, file 
name, literal, or data structure) that identifies the data to 
be used in a calculation operation. 


field: An area that is reserved and used for a particular 
item of information. 


field indicator: In RPG, an indicator used to indicate 
whether a given field in an input record is plus, minus, 
zero, or blank. 


field record relation indicator: In RPG, an indicator 
used to associate fields in an input record with a 
particular record type. The field record relation indicator 
is normally used when the record type is one of several 
in an OR relationship. 


field reference file: A physical file that contains no 
members and whose record format describes the fields 
used by a group of files. 


file: A generic term for the object type that refers to a 
data base file, a device file, or a set of related records 
treated as a unit. The system-recognized identifier for 
the object type is *FILE. 


file description: The information contained in the file 
that describes the file and its contents. 


file description specifications: An RPG coding form 
on which the programmer identifies and describes all 
files used in a program. 


file key: In RPG, all the key fields defined for a file. 


file operation code: |n RPG, an operation code (for 
example, CHAIN) that lets the user control the 
input/output operations to a file. 


file overrides: The file attributes specified at execution 
time that will override the attributes specified in the file 
description or in the program. 


file reference function: A CPF function that lets the 
user track file usage on the system. 


fold: To continue data for a line on the following 
printed or displayed line. Contrast with truncate. 


form: The area between perforations on continuous 
printer paper. 


format line: [n SEU, the abbreviated names of the 
fields in the source line that are displayed directly above 
the source line. The format line is displayed when the F 
(format) line command is executed. 
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full procedural file: In RPG, a file for which the input 
operations are controlled by programmer-specified 
operation codes instead of by the program cycle. 
Contrast with primary file. 


function check: A notification (by a message) that an 
unexpected condition has stopped the execution of a 
program. 


function key: A keyboard key that is used to request a 
specific system function. See also command function 
key. 


general-purpose library: The library provided by CPF to 
contain user-oriented, |BM-provided objects and 
user-created objects that are not explicitly placed in a 
different library when they are created. Named OQGPL. 


generic name: The initial characters common to object 
names that can be used to identify a group of objects. 
A generic name ends with an * (asterisk). For example, 
ORD* identifies all objects whose names begin with the 
characters ORD. 


heading: A constant, or field, usually at the top of a 
page or display, that identifies the information on the 
page or display. 


heading record: In RPG, output records that are 
generally printed at the top of a report and include 
report titles, column headings, or any other data needed 
to identify the information in the report. 


help text: Information that is associated with an 
information display, a menu, or a prompt that explains 
options or values displayed. Help text is requested by 
pressing the Help key. 


hexadecimal: Pertaining to a numbering system with a 
base of 16. Valid numbers are the digits O through 9 
and the characters A through F, where A represents 10 
and F represents 15. 


high-level language: A programming language that 
relieves the programmer from the rigors of machine level 
or assembler level programming; for example, RPG III 
and COBOL. Abbreviated HLL. 


history log: A log of information about system status 
and events. Named QHST. 


HLL: See high-level language. 


IDU: See /nteractive Data Base Utilities. 


immediate maintenance: A method of maintaining 
keyed access paths for data base files. This method 
updates the access path whenever changes are made to 
the data in the access path. Contrast with rebuild 
maintenance and delay maintenance. 


indexed file: A data base file whose access path is 
built on key values. Each record in the file is identified 
by a key field. 


indicator: (1) A 2-character entry on a specification 
form that is used to test a field or record or to tell when 
certain Operations are to be performed. (2) An internal 
switch used by a program to remember when a certain 
event occurs and what to do when the event occurs. 


information display: A display that presents 
information such as the status of the system to a user, 
but that rarely requests a response. 


informational message: A message that conveys 
information about the normal condition of a function. 


initial microprogram load: The process that loads the 
system microprogram code from the system auxiliary 
storage, then checks system hardware and prepares 
system programming for user operations. Abbreviated 
IMPL. 


initial program: A program, specified in a user profile, 
that is to be executed when the user signs on and the 
command processor program QCL is invoked. QCL 
invokes the initial program. 


initialize: To set to a starting position or value. 


inline data file: A file described by a //DATA 
command that is included as part of a job when the job 
is read from an input device by a reader program. 


input: Information (or data) to be processed. 


input-capable field: Any field that can receive input 
from a user. 


input field: A field in a display file into which data can 
be entered. An input field is passed from the device to 
the program when the program reads the record 
containing that field. 
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input file: A data base or device file that has been 
opened with the option to allow records to be read. 


input specifications: An RPG coding form on which 
the programmer describes the records and their fields in 
a program-described input file, adds RPG functions to 
an externally described input file, or defines a data 
structure and its subfields. 


Input stream: A group of records submitted to the 
system as batch input that contains CL commands for 
one or more jobs and/or the data records for one or 
more inline data files. 


inquiry: A request for information from a data file 
usually made against one record. 


inquiry message: A message that conveys information 
and that requests a reply. 


insert: The SEU operation during which source 
statements are keyed in and added as new records in a 
source member. 


Instruction: A statement that specifies an operation to 
be performed by the system and that identifies the data, 
if any, involved in that operation. 


integrity: The protection of data and programs from 
inadvertent destruction or alteration. 


interactive: Pertaining to a program or system that 
alternately accepts input and then responds. An 
interactive system is conversational; that is, a continuous 
dialog exists between the user and the system. 


Interactive Data Base Utilities: A System/38 licensed 
program that consists of DFU, SEU, query, and SDA. 
Abbreviated IDU. 


interactive job: A job in which the processing actions 
are performed in response to input provided by a work 
station user. During a job, a dialog exists between the 
user and the system. 


interactive processing: Pertaining to a program or 
procedure that alternately accepts input and then 
responds to the input. Contrast with batch processing. 


interactive subsystem: A subsystem in which 
interactive jobs are to be processed. IBM supplies three 
interactive subsystems: QCTL, QINTER, and QPGMR. 


internal storage: All main and auxiliary storage in the 
system. 


invocation: An instance of the execution of a program. 


invocation level: Identifies the occurrence of the same 
program in the job's invocation stack. An invocation 
level is used in debug mode only. The first occurrence 
of a program in a job has an invocation level of 1. 


invocation stack: A series of invocations linked 
together as a result of programs invoking other 
programs. 


invoke: To instruct a specific program to start 
executing. Same as Call. 


job: A single identifiable sequence of processing actions 
that represents a single use of the system. A Job is the 
basic unit by which work is identified on the system. 


job description: An object that contains information 
defining the attributes of a job. The system-recognized 
identifier for the object type is *JOBD. 


job log: A record of requests submitted to the system 
by a job, the messages related to the requests, and the 
actions performed by the system on the job. The job log 
is maintained by CPF. 


job message queue: A message queue that is created 
for each job. A job message queue is used for receiving 
requests to be processed (such as commands) and for 
sending messages that result from processing the 
requests. A job message queue consists of an external 
message queue and a set of program message queues. 
See also external message queue and program message 
queue. 


job name: The name of a job as identified to the 
system. For an interactive job, the job name is the name 
of the work station at which the job was initiated; for a 
batch job, the job name is specified in the command 
used to submit the job. Contrast with qualified job name. 


job number: A number assigned to a job as it enters 
the system to distinguish the job from other jobs. 


job priority: The order in which batch jobs on a job 


queue are selected for execution by CPF. More than 
one job can have the same priority. 
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job queue: An object that contains a list of batch jobs 
submitted to the system for execution and from which 
the batch jobs are selected for execution by CPF. The 
system-recognized identifier for the object type is 
*JOBQ. 


key field: A field in a record whose contents are used 
to sequence the records of a particular type within a file 
member. 


key in: The action of pressing keys on a keyboard to 
specify information that is to be processed. See also 
enter. 


keyed sequence: The order in which records appear in 
an access path. The access path is based on the 
contents of one or more key fields contained in the 
records. 


keyed sequence access path: An access path to a 
data base file that is ordered on the contents of key 
fields contained in the individual records. Contrast with 
arrival sequence access path. 


keyword: (1) A name that identifies a parameter. 
Keywords are used in CL commands and in DDS. (2) In 
RPG, a word whose use is essential to the meaning and 
structure of a statement in a programming language. 


label: (1) The name of a file on a diskette or tape. (2) 
An identifier of a command generally used for 
branching. (3) In RPG, a symbolic name that represents 
a specific location in a program. A label can serve as 
the destination point for one or more branching 
operations. 


level checking: A function that compares the record 
format level identifiers of a file to be opened with the 
file description that is part of a compiled program to 

determine if the file record format has changed since 
the program was compiled. 


library: An object that serves as a directory to other 
objects. A library is used to group related objects and to 
find objects by name when they are used. The 
system-recognized identifier for the object type is *LIB. 


library list: An ordered list of library names used to 
find an object. The library list indicates which libraries 
are to be searched and the order in which they are to be 
searched. The system-recognized identifier is *LIBL. 
*LIBL specifies to the system that a job’s current library 
list is to be used to find the object. 


licensed program: An |BM-written program that 
performs functions related to processing user data. 


line commands: |In SEU, commands (such as D for 
delete, | for insert, C for copy) that are keyed in the 
sequence number field of displayed records to request 
operations on source records. 


line counter specifications: An RPG coding form on 
which the programmer indicates or overrides the system 
defaults for the length of the printer form and the 
number of lines to print on a page. Line counter 
specifications can be used for each printer file in a 
program. 


listing: A printout usually containing the input and 
output of the compilation of a program, the creation 
(compilation) of an object, or the execution of a 
program. See also compiler listing. 


lock state: The definition of how an object is allocated, 
how it is used (read or update), and whether the object 
can be shared (used by more than one job). 


logical file: A description of how data is to be 
presented to or received from a program. This type of 
data base file contains no data, but it provides an 
ordering and format for one or more physical files. 
Contrast with physical file. 


logical file member: A logical grouping of data records 
in a logical file. See also member. 


magazine: A container that holds up to 10 diskettes 
and is inserted into a diskette magazine drive. 


main storage: All storage in a computer from which 
instructions can be executed directly. 


member: A description of a named subset of records in 
a physical or logical file. Each member conforms to the 
characteristics of the file and has its own access path. 
All |/O requests are directed to a specific member of a 
data base file. 


menu: A display in which a list of options is shown. 


message: A communication sent from one person or 
program to another person or program. 
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message queue: An object on which messages are 
placed when they are sent to a person or program. The 
system-recognized identifier for the object type is 
*MSGQ. 


modulus 10 checking/modulus 11 checking: A 
technique for validity checking that involves the 
association of digits with data. It is used in entering or 
updating fields in a data record. 


normal termination: System termination that results 
from the successful execution of the Power Down 
System (PWRDWNSYS) command. Contrast with 
abnormal termination. 


numeric field: An area that is reserved for a particular 
unit of information and that can contain only the 


numeric digits O through 9. Contrast with character field. 


object: A named unit that consists of a set of attributes 
(that describe the object) and, in some cases, data. An 
object is anything that exists in and occupies space in 
storage and on which operations can be performed. 
Some examples of objects are programs, files, and 
libraries. 


object authority: The right to use or control an object. 
See object rights and data rights. 


object name: The name of an object. Contrast with 
qualified object name. 


object owner: A user who creates an object or to 
whom the ownership of an object has been transferred. 
The object owner has complete control over the object. 


object rights: The authority that controls what a 
system user can do to an entire object. For example, 
object rights include deleting, moving, or renaming an 
object. There are three types of object rights: object 
existence, object management, and operational. 


object type: The attributes that define the purpose of 
an object within the system. Each object type has 
associated with it a set of commands with which to 
process that type of object. 


object user: A user who has been authorized by the 
object owner, the security officer, or a user with object 
existence rights to perform certain functions on an 
object. 


omit function: A CPF function that determines which 
records from a physical file are to be omitted from a 
logical file's access path. Contrast with select function. 


open: The function that connects a file to a program for 
processing. Contrast with close. 


operation: A defined action performed on one or more 
data items, such as adding, multiplying, comparing, or 
moving information. 


operation code: In RPG, a word or abbreviation, 
specified in the calculation specifications, that identifies 
an operation. 


operator/service panel: A panel located adjacent to 
the system console on the system unit. This panel 
contains lights and switches that are used primarily 
when the system is started or serviced. 


output: Data transferred from storage to an output 
device. 


output file: A data base or device file that has been 
opened with the option to allow records to be written. 


output indicator: In RPG, an indicator used to define 
the conditions under which an output record or an 
output field in the output specifications is written. An 
Output indicator must be previously defined before it is 
used in the output specifications. 


output priority: The priority used to determine the 
order in which spooled output files produced by the job 
are to be written. More than one file can have the same 
priority. 


output queue: An object that contains a list of output 
files to be written to an output device by a writer. The 
system-recognized identifier for the object type is 
*OUTQ. 


output specifications: An RPG coding form on which 

the programmer describes the records and their fields in 
a program-described output file or adds RPG functions 

to an externally described output file. 


page: (1) A 512-byte block of information that can be 
transferred between auxiliary storage and main storage. 
(2) Each group of records in a subfile that are displayed 
concurrently. (3) One printer form. 
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page-in: The process of transferring a page from 
auxiliary storage to main storage. 


page-out: The process of transferring a page from main 
storage to auxiliary storage. 


parameter: (1) Data passed to or received from another 
program. (2) In CPF, an argument that identifies an 
individual value or group of values to be used by a 
command to tailor a function requested through the 
command. 


password: A unique string of characters that a system 
user enters to identify himself to the system. 


physical file: A description of how data is to be 
presented to or received from a program and how data 
is actually stored in the data base. A physical file 
contains one record format and one or more members. 
Contrast with logical file. 


physical file member: A subset of the data records in 
a physical file. See also member. 


preexecution-time array or table: In RPG, an array or 
table that is loaded at the same time as the source 
program, before actual execution of the program begins. 
See also compile-time array or table and execution-time 
array. 


primary file: In RPG, if specified, the main file from 
which RPG first reads a record in the program cycle. In 
multifile processing, the primary file is used to determine 
whether the MR indicator is set on. Contrast with full 
procedural file. 


printer file: A device file created by the user to support 
a printer device. 


printer/display layout: A coding form on which the 
programmer can design the format for a printed report 
or a display. 


priority: The relative significance of one job to other 
jobs in competing for allocation of resources. 


problem determination: The process of determining 
the source of a problem as a component problem, a 
machine failure, €@ common carrier link, a user-supplied 
element, or a user error. 





procedural programming: In RPG, a programming J 
technique in which the input and output operations are 

controlled by programmer-specified operation codes 

instead of by the program cycle. 


processing: The action of performing operations on 
input data. 


processor: The functional unit that interprets and 
executes instructions. Same as processing unit and 
CPU. 


production library: A library containing objects needed 
for normal processing. Contrast with test library. 


program: An object that contains a set of instructions 
that tell a computer where to get input, how to process 
it, and where to put the results. A program is created as 
a result of a compilation. The system-recognized 
identifier for the object type is *PGM. 


program cycle: In RPG, a series of steps performed by 
a compiled RPG program in a specific order for each 
primary or secondary record that is read. 


program data: The data associated with a program. ) 


program-described data: Data contained in a file for 
which the fields in the records are described in the 
program that processes the file. Contrast with externally 
described data. 


program-described file: A file for which the fields in 
the records are described only in the program that 
processes the file. To CPF, the record is viewed as a 
character string. Contrast with externally described file. 


program message queue: A message queue used to 
hold messages that are sent between program 
invocations of a routing step. The program message 
queue is part of the job message queue. 


program variable: A named changeable value that can 
exist only within programs. Its value cannot be obtained 
or used when the program that contains it is no longer 

invoked. 


prompt: A displayed request for information or user 
action. The user must respond to allow the program to 
proceed. 


protected field: A field in a display file in which data > 
cannot be keyed, changed, or erased. 





QGPL: See general-purpose library. 


qualified job name: A job name and its associated user 
name and a system-assigned job number. Contrast with 
job name. 


qualified object name: An object name and the name 
of the library containing the object. Contrast with object 
name. 


query: (1) A utility that is part of the Interactive Data 
Base Utilities licensed program. (2) A request to extract, 
from a file, one or more records based upon some 
combination of data. 


query application: See application. 


queue: A line or list formed by items in the system 
waiting for service; for example, work to be performed 
or messages to be displayed. 


reader: A program that reads jobs from an input device 
or a data base file and places them on a job queue. 


rebuild maintenance: A method of maintaining keyed 
access paths for data base files. This method updates 
the access path only while the file is open, not when the 
file is closed; the access path is rebuilt when the file is 
opened. Contrast with immediate maintenance and delay 
maintenance. 


record: An ordered set of fields that make up a single 
occurrence of the basic unit of data transferred between 
a file and a program. 


record class: In the query utility, one of the distinct 
groups into which the query utility classifies records 
during the preparation of a table. 


record format: The definition of how data is structured 
in the records contained in a file. The definition includes 
the record name, field names, and field descriptions 
(such as length and data type). The record formats used 
in a file are contained in the file’s description. 


record identification code: In RPG, characters placed 
in a record to identify that record type. 


record identifying indicator: In RPG, an indicator that 
identifies the record just read. 


record type: In RPG, the classification of records in a 
file. Records of the same type have the same fields in 
the same order. For program-described files, these 
records have record identification codes; for externally 
described files, the records have the same record format 
name. 


recovery: The act of resetting the system, or data 
stored in the system, to an operable state following 
damage. 


relational operator: In CL, an operator that can be 
used in an arithmetic, character, or logical relation to 
indicate the comparison to be performed between the 
terms in the relation. The relational operators are *EQ or 
= (equal to), *GT or > (greater than), *LT or < (less 
than), *GE or >= (greater than or equal to), *LE or <= 
(less than or equal to), *NE or “= (not equal to), *NG or 
—> (not greater than), *NL or ~< (not less than). 


relative end position: In RPG, an entry on the output 
specifications that indicates the number of blank 
positions that are to appear between a field or constant 
and the field or constant defined on the preceding 
specification line. Contrast with exact end position. 


request: A CL command, the selection of an option on 
a menu, or the entering of data that instructs the system 
to perform a function. A CL command can be entered 
interactively or in a batch job. A request is identified as 
RQS on the job log. 


request data: Data to be put in a job message queue 
that is used by a job. For example, a single command 
or group of commands. 


response indicator: A 1-character field passed with an 
input record from CPF to a program to provide 
information about the data record or actions taken by 
the work station user. 


restore: To transfer specific objects or libraries from 
magnetic media such as diskettes or tape to internal 
storage by reconstructing them in internal storage. 
Contrast with Save. 


return indicator: In RPG, an indicator used to indicate 
to the internal RPG logic that control should be returned 
to the calling program. Abbreviated RT. 


right-adjust: To place an entry in a field or to move the 


contents of a field so that the rightmost character of the 
data is in the rightmost position of the field. 
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routing data: A character string that CPF compares 
with character strings in the subsystem description 
routing entries to select the routing entry that is to be 
used to initiate a routing step. Routing data can be 
provided by a work station user, specified in a 
command, or provided through the job description for 
the job. 


routing entry: An entry in a subsystem description that 
specifies the program to be invoked to control a routing 
step that executes in the subsystem. 


routing step: The processing performed as a result of 
invoking a program specified in a routing entry. 


RQS: See request. 


save: To duplicate specific objects or libraries by 
transferring them from internal storage to magnetic 
media such as diskettes or tape. Contrast with restore. 


scan: The SEU operation in which records are searched 
for a specified character string or syntax error. 


screen design aid: The utility of the Interactive Data 
Base Utilities licensed program that is used to 
interactively design, create, and maintain display record 
formats and menus. Abbreviated SDA. 


SDA: See screen design aid. 


security: The control of access to, or use of, data or 
functions. 


security officer: The individual at an installation who is 
designated to control the authorization of functions and 
data in System/38. 


select function: A CPF function that determines which 
records from a physical file are to be selected for a 
logical file's access path. Contrast with omit function. 


select/omit field: A field in a logical file record format 
whose value is compared with a constant, the contents 
of another field, a range of values, or a list of values to 
determine if a record is to be omitted from the access 
path of the logical file or selected for use by the logical 
file. See also omit function and select function. 


sequence checking: An RPG function that checks the 
sequence of records in input, update, or combined files 
used as primary and secondary files. 


sequence number: The number of a record that , 
identifies the record within the source member. 


sequential-by-key processing: A method of file 
processing that reads records from a keyed sequence 
file in the order in which the keys are arranged in the 
access path. 


sequential file: A file in which records are processed in 
the order that they are stored in the file. of contention 
and error recovery, and the characteristics of the data 
stream. Sessions compete for network resources such 
as the class of service within the path control network. 
See also half-session. Note: Each session is uniquely 
identified in a TH by a pair of network addresses, 
identifying the origin and destination NAUs of any 
transmissions exchanged during the session. 


SEU: See source entry utility. 


shared access path: An access path used by more 
than one file to provide access to data common to the 
files. 


sign off: To enter a command or to select an option 
from a menu at a work station that instructs the system , 
to end an interactive job. ) 


sign on: To enter a password that identifies the user to 
the system and instructs the system to establish an 
interactive job at a work station. 


single-level storage: The technique of addressing 
multiple levels of storage through a single addressing 
structure. 


source entry utility: The utility of the Interactive Data 
Base Utilities licensed program that is used to create 
and change source members. Abbreviated SEU. 


source file: A file created by the specification of 
FILETYPE(*SRC). A source file can contain source 
statements for such items as high-level language 
programs and data description specifications. 


source listing: A portion of a compiler listing that 
contains source statements and diagnostics. See also 
compiler listing. 


source member: A member of a data base source file 
that contains source statements such as RPG, COBOL, 
or DDS specifications. See also member. / 3 


source program: A set of instructions, written in a 
programming language such as RPG or COBOL, that 
represents a particular job as defined by a programmer. 
A source program is used as input to the compiler to 
create an executable program. 


source statement: A statement written in symbols of a 
programming language. For example, RPG, COBOL, or 
DDS specifications are source statements. 


spooled file: A generic term for three types of files: a 
device file that provides access to an inline data file or 
that creates a spooled output file, an inline data file, or a 
spooled output file. 


spooled input file: See inline data file. 


spooled output file: A device file that causes output 
data to be saved for later processing by a writer. 


spooling: The CPF-provided execution-time support 
that reads and writes input and output streams on an 
intermediate device in a format convenient for later 
processing or output. 


spooling subsystem: A subsystem that provides the 
operating environment needed by the CPF programs that 
read jobs onto job queues and write files from the 
output queues. IBM supplies one spooling subsystem: 
QSPL. 


storage pool: A logical segment of main storage 
reserved for executing a group of jobs. 


subfile: A group of records of the same record format 
that can be displayed concurrently at a work station. 

The system sends the entire group of records to the 
wurk station in a single operation and receives the group 
in another operation. 


subfile record format: One of two record formats 
required to define a subfile in DDS. The subfile record 
format defines the fields in a subfile record and is used 
by the program to perform input, output, and update 
operations to the subfile. 


subroutine: (1) In data communications, a group of 
statements in a program that can be executed several 
times in that program. (2) In RPG, a group of calculation 
specification statements in a program that can be 
executed several times in that program. 


subsystem: An operating environment, defined by a 
subsystem description, through which CPF coordinates 
work flow and resource usage. 


subsystem description: An object that contains 
information defining a subsystem and that CPF uses to 
control the subsystem. The system-recognized identifier 
for the object type is *SBSD. 


syntax checking: A function of the command analyzer, 
a compiler, or SEU that checks single statements for 
violations of the rules governing the structure of the 
statement. 


system console: The keyboard and display screen on 
the system unit that serve as a work station for 
communicating with and controlling the system. See 
also operator /service panel and work station. 


system date: The date established for the system 
when it is started. 


system library: The library provided by CPF to contain 
system-oriented objects provided as part of CPF. 
Named QSYS. 


system operator: The person who operates the system 
and looks after the peripheral equipment necessary to 
Initiate computer runs or finalize the computer output in 
the form of completed reports and documents. 


system operator message queue: The message queue 
used by the system operator to receive and reply to 
messages from the system, work station users, and 
application programs. Named QSYSOPR. 


system termination: The state in which all processing 
on the system is stopped. Depending on the cause of 
the termination, system power could be shut off (such 
as by a power interruption or by entering the Power 
Down System (PWRDWNSYS) command) or could 
remain on (such as caused by a machine error 
condition). See also abnormal termination and normal 
termination. 


system time: The elapsed time from the point where 
the system was started to the current time. If the 
system time is changed to the local time when the 
system is started, the current system time is the local 
time of day. 
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system unit: The main unit of the system, which 
contains the processing unit, the system console 
keyboard/display, the operator/service panel, the 
diskette magazine drive, main storage, auxiliary storage, 
the work station controller, and the communications 
subsystem. 


system value: A value that contains control information 
for the operation of certain parts of the system. A user 
can change the system default value to tailor the system 
to his working environment. System date and library list 
are examples of system values. 


temporary library: A library that is automatically 
created for each job to contain temporary objects that 
are created by that job. The objects in the temporary 
library are deleted when the job ends. Named QTEMP. 


terminal: |n data communications, same as work 
station. 


termination: The act of putting the system or an 
element of the system (such as CPF or a subsystem) in 
the state where it no longer performs its normal 
function. See also system termination. 


test library: A library to be used in debug mode and 
that does not contain objects needed for normal 
processing. Contrast with production library. 


timestamp: (1) To apply the current system time. (2) 
The value on an object that is an indication of the 
system time at some critical point in the object's history. 
(3) In query, the identification of the day and time a 
query report was created that query automatically 
provides on each report. 


transaction: (1) In a batch or remote batch entry, a job 
or job step. (2) An exchange between a terminal and 
another device that accomplishes a particular action or 
result; for example, the entry of a customer's deposit 
and the updating of the customer's balance. (3) A 
specific set of input data that triggers the execution of a 
specific processor job; a message destined for an 
application program. (4) A unit of processing (consisting 
of one or more application programs) initiated by a 
single request. In many cases, the request will originate 
at a terminal (work station). 


user name: The name by which a particular user is 
known to the system. 


user password: A unique string of characters that a 
system user enters to identify himself to the system. 


user profile: An object that contains a description of a 
particular user or group of users. A user profile contains 
a list of authorizations to objects and functions. The 
system-recognized identifier for the object type is 
*USRPRF. 


utility definition specification: A group of source 
statements, which have the same syntax as CL 
commands, from which a DFU or query application is 
created. Abbreviated UDS. 


variable: A named modifiable value. The value can be 
accessed or modified by referring to the name of the 
variable. 


verify: [In DFU, a method of checking the accuracy of 
entered data by entering it twice and comparing the 
second entry with the first. 


virtual storage: The combination of main storage and 
auxiliary storage, treated as a single addressable unit. 
Abbreviated VS. 


work station: A device that lets a person transmit 
information to or receive information from a computer as 
needed to perform his job. 


work station message queue: A message queue that 
iS associated with a particular work station and that is 
used for sending and receiving messages sent to the 
work station. The name of the message queue is the 
Same as the name of the work station. 


work station user: A person who uses a work station 
to communicate with System/38. 


work station user profile: The CPF-supplied user 
profile that has the authority necessary for work station 
users. Named QUSER. 


working display: See basic working display. 
writer: A CPF program that writes spooled output files 


from an Output queue to an external device, such as a 
printer. 
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// DATA statement (see DATA command) 

// ENDJOB statement (see ENDJOB command) 
// JOB statement (see JOB command) 

*SRC 3-9 


access paths 
definition G-1 
introduction to 4-2 
multiple 4-4, 8-34 
ACTTYP (account type) field 1-2, 4-8 
ADDTN format 11-14 
administrative programmer A-1 
application 
definition G-1 
DFU (data file utility) 
MLG110U 7-3 
MLG230U 8-34 
MLG315U 8-3 
mailing list 
(see mailing list application) 
query (MLG910Q) 8-43 
application control prompt (DFU) 
in MLG110U 7-8 
in MLG230U 8-37 
in MLG315U 8-6 
application creation prompt 
in DFU 
MLG110U 7-16 
MLG315U 8-12 
in query (MLG910Q) 8-51 
application-oriented menu B-1, 8-22 
application requirements, typical 1-3 
applications, critical A-/7 
applying transactions to master file 
(MLG311) 7-20 
approach to using libraries A-1 
approaches to mailing list application 
(see mailing list application) 
arrays, compile-time 
definition G-2 
RPG program MLG310 4-21 
RPG program MLG320 11-22 
audit control prompt (DFU) 
in MLG110U 7-14 
in MLG230U 8-39, 8-42 
in MLG315U 8-11 
auto dup 
definition G-1 
indicator 7-18 
auto increment indicator 7-18 


Index 


backup 
online (copy file) A-8 
save/restore 2-13 
basic field definition prompt (DFU) 
in MLG110U 7-10 
in MLG230U 8-38 
in MLG315U 8-8 
basic functions 2-2 
basic working display 
definition G-1 
using programmer menu as’ 5-2 
batch header record 10-2 
batch input and batch maintenance 
multiple diskette input 9-1 
single diskette input 4-1 
batch job 
concept 2-2 
definition G-1 
examples 
creating file 4-6, 4-2/7 
creating program 3-8, 4-22 
executing application 8-52 
executing program 3-11, 4-22, 7-24 
use 
submitted from diskette 3-6 
submitted from work station 7-24 
batch jobs submitted from menu 
application menu B-3 
programmer menu 
to call program 7-24 
to execute application 8-52 
batch maintenance with 
batch input 
from multiple diskettes 9-1 
from single diskette 4-1 
interactive input 
from multiple work stations 10-1 
from single work station 7-1 
batch subsystem (QBATCH) 
definition G-1 
description 2-6 
use for batch jobs 3-9 
batches of transactions from multiple 
users 10-1 
BATNUM, BATDAT, BATSTS, BATDSC 
fields 10-2 
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CA and CF keys, difference 10-18 
calculation specifications (RPG) 
definition G-2 
MLG105 program 10-20 
MLG310 program 4-13 
MLG320 program 11-16 
CALL command 
(see also calling program) 


examples 
in CL programs B-5, B-9, B-11, 8-18, 
8-23, 9-2 
in input stream 3-11, 4-22, 4-27, 9-2, 
9-6 

use 


executing Program DSKTCPY 9-4 
executing program MLGO35C_ 8-23 
executing program MLG310 4-1 
executing program MLG310 4-22 
executing program MLG310 9-1,9-7 
executing program MLG520_ ‘3-1 
executing program MLG525 4-2 
executing program 
SETLIBL 6-20, 8-23 
general 3-12 
call menu, program 8-16 
calling program 
definition G-2 
from another program (examples) 
CL program MLGOOS5C 8-23 
CL program MLG315C 8-18 
in Menu approach B-9 
from batch job 
submitted from diskette 3-11 
submitted from work station B-5, 7-24 
from work station 
using program call menu 8-19 
using programmer menu 7-23 
CF key (see command function key) 
CHANGE format 11-13 
CHGDTA (change data) command 
use in CL program (examples) 8-18, 8: 
use in DFU 
executing application MLG110U 7-17 
executing application 
MLG315U 8-13, 8-18, 8-26 
CHGVAR (change variable) command, 
using B-6, B-9 
CHGVAR (change variable) 
command, using B-10 
CL (control language) program 
calling 
(see also calling 
program) 6-20, 8-19, 9-4 
definition G-2 
DSKTCPY (copy diskettes) 9-4 
MLGOOS5SC (set application 
environment) 8-23 
MLGO35C (display user menu) 8-26, 8-32 
MLGO36C (display menu to submit 
batch) B-5 


1 
7 


CL (control language) program (continued) 
MLG315C (execute DFU application) 8-19 
SETLIBL (set library list) 6-18 
using data area for job description B-7 
using single variable character 
value B-8 
with commands using fixed values B-5 
with commands using numeric and character 
values B-10 

CLRPFM (clear physical file member) 

command, using 7-25, 9-4 
coding examples 
CL programs 
to copy diskettes 9-5 
to display menu B-5, 8-26 
to execute application 8-18 
to set application environment 8-23 
to set library list 6-18 
using data area B-/7 
using fixed values B-5 
using variable values B-8, B-10 
display files 
for interactive maintenance 
program 11-10 
for mailing list menu B-4, 8-24 
for transaction entry program 10-13 
field reference file 6-26, 10-3 
header file 10-4 
master files 
logical 4-26, 6-32, 8-35, 10-6 
physical 4-7, 6-31 
RPG programs 
batch maintenance 4-11, 7-22 
interactive maintenance 11-15 
label printing 3-2 
mailing list print 4-23 
transaction entry 10-19 
transaction files 
logical 6-36, 10-6 
physical 6-34 

COLHDG keyword 6-27 

command function keys 
CA and CF keys, difference 10-18 
CF1 

end menu definition (SDA) 8-31 
end program (MLG105 display) 10-10 
end program (MLG320) 11-5 
exit application 7-19, 8-15, 8-26 
exit DFU 7-16, 8-12 
exit query 8-51 
exit SDA 8-32 
exit SEU edit display 5-12 
CF1i1 (replace existing object) 6-22 
CF12 (SEU lowercase) 6-27 
CF3 (end batch, MLG105) 10-18, 10-24 
CF4 (prompting request) 5-4, 6-22 
CF5 
confirm deletion 
(MLG320) 11-8, 11-14, 11-20 
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command function keys (continued) 

CF5 (continued) 
continue batch (MLG105) 10-18 

CF6 
auto dub (MLG110U) 7-18 
display messages (programmer 
menu) 6-23 
review transaction 
(MLG105) 10-18, 10-24 


CF7 

auto increment 7-18 

cancel request 11-7, 11-8, 11-13, 11-14, 11-2 
CF9 


add record (MLG110U) 7-19 
add record (MLG315U) 8-15 
definition G-2 
keyboard template 7-4 
command prompting 5-4 
commands using fixed values B-5 
commands, using 
CALL (see CALL command) 
CHGDTA (see CHGDTA command) 
CHGVAR (change variable) B-6, B-9, B-10 
CLRPFM (clear physical file 
member) 7-25, 9-4 
CPYF (copy file) 4-2, 9-4 
CRTDTAARA (create data area) A-3 
CRTJOBD (create job description) 6-14 
CRTLF (create logical file) 4-27 
CRTLIB (create library) 5-3, 6-10 
CRTPF (create physical file) 4-6 
CRTRPGPGM (see CRTRPGPGM command) 
CRTSRCPF (create source physical 
file) 6-11 
CRTUSRPRF (create user profile) 8-21 
DATA (see DATA command) 
DCL (declare variable) B-9, B-11 
DCLDTAARA (declare data area) B-7 
DCLF (declare file) B-6, 8-26 
DO (do) B-6 
DSPDTA (display data) 
ENDDO (end do) B-6 
ENDJOB (see ENDJOB command) 
ENDPGM (see ENDPGM command) 
GOTO (go to) B-5, 8-26 
GRTOBJAUT (grant object authority) 9-3 
JOB (see JOB command) 
MONNSG (monitor message) 9-4 
OVRDBF (see OVRDBF command) 
OVRDKTFE (override with diskette 
file) 9-4 
PGM (see PGM command) 
PWRDWNSYS (power down system) 2-12 
RCVDTAARA (receive data area) B-7 
RETURN (return) B-2, B-5 
RPLLIBL (replace library list) A-3, 
6-16, 6-18 


8-29, 8-30, 8-40 


commands, using (continued) 
RVKOBJAUT (revoke object authority) A-3 
SBMJOB (submit job) B-6, B-7, B-10 
SIGNOFF (sign off) B-5, 8-26, 8-30 
SNDRCVF (send/receive file) B-5, 8-26 
STRDBRDR (start data base reader) 9-4 
STRDKTRDR (start diskette 
reader) 3-7, 3-12, 4-6, 4-22, 4-25, 4-27 
STRPRTWTR (start printer 
writer) 2-12, 3-10 
STRSBS (start subsystem) 2-11 
comment (CL) 3-11 
compile-time arrays 
definition G-2 
RPG program MLG310 4-21 
RPG program MLG320 11-22 
compiler listing 
definition G-2 
printing 3-10 
compiling program 3-10 
considerations 
for mailing list example 1-7 
recovery (see recovery considerations) 
control and file description specifications 
(RPG) 
definition G-3, G-5 
MLG105 program 10-19 
MLG310 program 4-11 
MLG311 program 7-22 
MLG320 program 11-15 
MLG520 program 3-2 
MLG525 program 4-23 
control language program (see CL program) 
conventions, naming 1-4 
CPF (control program facility) 
definition G-3 
Starting 2-10 
terminating (powering down) 2-12 
CPYF (copy file) command, using 4-2, 9-4 
creating 
(see also CL program; data file 
utility; display file; field reference 
file; master file; query utility; RPG 
program; source files; transaction file) 
CL program 
MLGOO5C 8-23 
MLGO35C 8-26, 8-32 
MLG315C 8-18 
SETLIBL 6-16 
DFU application 
MLG110U 7-5 
MLG230U 8-36 
MLG315U 8-4 
display file MLGO35CD 8-24, 8-31 
field reference file MLGREFP 6-25 
job description 6-14 
library 6-10 
master file 
MLGMASL 4-27 
MLGMASP 4-6 
MLGMSTL 6-32 
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creating (continued) 
master file (continued) 
MLGMSTL2 8-35 
MLGMSTP_ 6-30 
menu 
from DDS 8-24 
using SDA 8-27 
program 
from input stream 3-6 
from work station 6-16 
query application MLG910Q_ 8-44 
RPG program 


MLG310 4-22 
MLG311 7-20 
MLG520 3-6 
MLG525 4-25 
source files 6-11 


transaction file 
MLGTRNL 6-35 
MLGTRNP_ 6-33 
user profile 8-21 
critical applications A-/7 
CRTDTAARA (create data area) command, 
using A-3 
CRTJOBD (create job description) command, 
using 6-14 
CRTLF (create logical file) command 4-27 
CRTLIB (create library) command 5-3, 6-10 
CRTPF (create physical file) command 4-6 
CRTRPGPGM (create RPG program) command 
examples 
creating MLG310 4-22 
creating MLG520 3-6, 3-8 
use 3-9, 3-10 
CRTSRCPF (create source physical file) 
command 6-11 
CRTUSRPRF (create user profile) command, 
using 8-21 
current date and time 2-10 


daily operations 2-9 
damage (see recovery considerations) 
data 
identifying by // DATA 3-9, 3-11, 4-6 
reading from diskette 3-6, 9-2 
DATA (data) command (// DATA) 
examples (input stream) 
creating file 4-6, 4-27 
creating program 3-6, 3-8, 4-22 
executing program 3-11, 4-22, 9-2, 9-6 
use in 
creating file 4-6 
creating program 3-9, 4-25 
executing program 3-2, 3-11 
data area (for a job description) B-7 


data base 
definition G-3 
use 4-2 
data base file 
(see also field reference file; header 
file; logical file: master file; physical 
file; source file; transaction file) 
definition G-3 
introduction to 4-2 
data description specifications (DDS) 
definition G-3 
edit codes, using 6-27 
field reference file, 
specifying 6-30, 6-34, 10-16 
key field, 
specifying 4-7, 4-26, 6-32, 6-36 
keywords, using 
COLHDG- 6-27 
EDTCDE 6-2/7, 10-3 
PFILE 4-26, 6-32, 6-36, 8-35 
REF 6-30, 6-34, 10-16, 11-13 
RTNDTA 11-23 
SETOFF' 8-5, 11-13 
SFL 10-17 
SFLCTL 10-17 
SFLINZ, SFLPAG, SFLSIZ 10-17 
TEXT 6-27 
UNIQUE 4-7, 6-32, 10-6 
UNLOCK 10-17 
record format, specifying 4-7 
specifications for 
MLGENTL 10-6 
MLGHDRP_ 10-4 
MLGMASL 4-26 
MLGMASP 4-7 
MLGMSTL 6-32 
MLGMSTL2 8-35 
MLGMSTP 6-31 
MLGREFP 6-26, 10-3 
MLGTRNL 6-36 
MLGTRNP 6-34 
MLGO35CD 8-24 
MLGO3S6CD 8B-4 
MLG105D- 10-13 
MLG320D 11-9 
use (general) 4-5 
data entry program, transaction 10-7 
data file 
definition G-3 
externally described 4-5 
data file utility (DFU) 
(see also DFU displays) 
application programs 
MLG110U (interactive transaction 
entry) 7-3 
MLG230U (inquiry) 8-34 
MLG315U (interactive maintenance) 8-3 
creating application programs 
MLG110U 7-4 
MLG230U 8-36 
MLG315U 8-4 











data file utility (DFU) (continued) 
definition G-3 
executing application programs 
MLG110U 7-17 
MLG230U 8-40 
MLG315U 8-13 
use /-3 
data file, inline (see inline data file) 
data independence 6-30 
date and time, current 2-10 
DCL (declare variable) command, 
using B-9, B-10 
DCLDTAARA (declare data area) command, 
using B-/7 
DCLF (declare file) command, using B-6, 
8-26 
DDS (see data description specifications) 
DDS keywords (see keywords) 
defining fields in files 4-5 
described data files, externally 4-5 
description, job (see job description) 
device file 
(see also display file) 
definition G-4 
use (general) 2-5 
use in program 3-3 
DFU (see data file utility) 
DFU create/change menu 
in MLG110U 7-6 
in MLG230U_ 8-36 
in MLG315U) 8-5 
DFU create prompt 
in MLG110U 7-7 
in MLG230U 8-36 
in MLG315U 8-6 
DFU displays 
application control prompt 
MLG110U 7-8 
MLG230U 8-37 
MLG315U 8-6 
application creation prompt 
MLG110U 7-16 
MLG315U 8-12 
audit control prompt 
MLG110U 7-14 
MLG230U 8-39, 8-42 
MLG315U 8-11 
basic field definition prompt 
MLG110U 7-10 
MLG230U 8-38 
MLG315U 8-8 
DFU create/change menu 
MLG110U 7-6 
MLG230U 8-36 
MLG315U 8-5 
DFU create prompt 
MLG110U 7-7 
MLG230U 8-36 
MLG315U 8-6 


DFU displays (continued) 
DFU menu 
MLG110U 7-6 
MLG315U 8-5 
entry format definition prompt 
MLG110U 7-10, 7-13 
MLG230U- 8-38 
MLG315U 8-7, 8-10 
exit application definition menu 
MLG110U 7-15 
MLG315U 8-11 
exit application prompt 
MLG110U 7-19 
MLG315U 8-15 
extended field definition prompt 
(MLG110U) 7-11 
field review prompt (MLG110U) 7-9 
file review prompt 
MLG110U 7-8 
MLG230U_ 8-37 
MLG315U 8-7 
validity check prompt (MLG315U) 8-9 
DFU displays (executing application) 
MLG110U 7-17 
MLG230U 8-40 
MLG315U 8-13 
DFU menu 
in MLG110U) 7-6 
in MLG315U) 8-5 
diskette copy program (DSKTCPY) 9-4 
diskette label 3-6 
diskette, reading data from 3-6, 9-2 
display (on work station) 
application-oriented menu B-1, 8-22, 8-33 
DFU (see DFU displays) 
inquiry 8-40 
interactive maintenance 8-14, 11-5 
library list 6-8 
program call menu 8-16, 8-19 
programmer (See programmer menu) 
prompt for command 5-5, 8-29, 8-30 
query (see query displays) 
SDA (see SDA displays) 
SEU (see SEU displays) 
sign-on 2-9 
start control program facility 2-10 
submitted jobs 6-23 
system operator (see system operator 
menu) 
transaction entry 7-18, 10-10 
working (see basic working display) 
display file 
declaring in program (CL) 8-26 
definition G-4 
MLGO35CD (user menu) 
creating from DDS 8-24 
creating through SDA_ 8-27 
MLGO36CD (menu to submit batch) B-4 
MLG105D (MLG105 program) 10-13 
MLG320D (MLG320 program) 11-9 
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display file (continued) 
specifying in program (RPG) 10-19, 11-15 
display/printer layout (see printer/display 
layout) 
dispiay station 
definition G-4 
requirements for this application 1-6 
displaying messages 
(see also messages) 
program call menu 8-17 
programmer menu 6-23 
displaying submitted jobs 6-23 
distributed data system (IBM 5280) 1-6, 
3-6 
do group 
definition G-4 
use B-5, 11-14 
DO operation (RPG) 11-14 
DSKTCPY CL program 9-4 
DSPDTA (display data) command, using 
8-30, 8-40 8-29 
DSPLY format 11-14 


edit code 
definition G-4 
use 6-2/7 
EDTCDE keyword 6-27, 10-3 
ENDJOB (end job) command (// ENDJOB) 
examples (input 
stream) 3-6, 3-8, 3-11, 4-6, 4-22, 4-27 
use 3-9 
ENDPGM (end program) command 
examples B-5, B-9, B-11, 6-18, 8-18, 8-23 
examples 8-26 
use 6-18 
entering transactions 
from diskette 4-22 
using DFU application 
MLG110U 7-1 
MLG315U_ 8-1 
using RPG program 
MLG105_ 10-1 
MLG320 11-1 
entry format definition prompt (DFU) 
in MLG110U 7-10, 7-13 
in MLG230U 8-38 
in MLG315U_ 8-7, 8-10 
examples 
(see also calling program; creating; 
data description specifications; 
executing) 
access paths 4-3 
CL program 
to copy diskette files 9-5 
to display menu B-5, 8-26 
to execute application 8-18 
to set application environment 8-23 


examples (continued) 
CL program (continued) 
to set library list 6-18 
using fixed values B-5 
using variable values B-8, B-10 
DFU application 
inquiry 8-34 
interactive maintenance 8-3 
transaction entry 7-3 
display file 
for interactive maintenance 
program 11-9 
for mailing list menu B-4, 8-24 
for transaction entry program 10-13 
displays (on work station) 
application-oriented menu B-1, 8-22, 
8-33 
DFU (see DFU displays) 
inquiry 8-40 
interactive maintenance 8-14, 11-5 
library list 6-8 
program call menu 8-16, 8-19 
programmer (see programmer menu) 
prompt for command 5-5, 8-29, 8-30 
query (see query displays) 
SDA (see SDA displays) 
SEU (see SEU displays) 
sign-on 2-9 
start control program facility 2-10 
submitted jobs 6-23 
system operator (see system operator 
menu) 
transaction entry 7-18, 10-10 
field reference file 6-26 
header file 10-4 
input stream 
to contain multiple jobs 9-2 
to create file 4-6, 4-27 
to create program 3-6, 3-8, 4-22 
to execute program 3-11, 4-22, 9-6 
keyboard template 7-4 
library list 
default user 6-/, 6-8 
IBM-shipped 6-7 
using 6-4 
master files 
logical 4-26, 6-32, 8-35 
physical 4-7, 6-31 
Output, printed 
mailing labels 3-13 
maintenance report 8-16, 11-6, 11-7 
query report 8-53 
query application 8-43 
record, mailing list 1-2 
RPG programs 
batch maintenance 4-9, 7-22 
interactive maintenance 11-2 
label printing 3-2 
mailing list print 4-23 
transaction entry 10-7 











examples (continued) 
SDA (creating menu) 8-27 
SEU 
adding source 5-9 
changing source 5-13 
member list 5-14 
source files 5-7 
source member 
for CL program 6-18, 8-18 
for field reference file 6-28 
for RPG program 5-11, /-21 
starting diskette reader 3-7 
starting printer writer 2-12 
Starting subsystem 2-11 
transaction files 
logical 6-36, 10-6 
physical 6-34 
EXCPT operation (RPG) 4-13, 4-21 
executing 
(see also calling program: creating) 
application 


directly from programmer menu 7-1/7, 


8-13 
from program call menu 8-19 
from user menu 8-23 
in batch job 8-52 
through CL program 8-17 
CL programs 
MLGO35C 8-23 
MLG315C 8-19 
SETLIBL 6-20 
definition G-5 
DFU applications 
MLG110U 7-17 
MLG230U 8-40 
MLG315U 8-13, 8-17, 8-23 
program 
from input stream 3-11 
from work station 7-23 
in batch job B-3, 3-11, 7-24 
query application MLG910Q 8-52 
RPG programs 
MLG105 10-7 
MLG310 4-22, 9-7 
MLG311 7-23 
MLG320 11-2 
MLG520 3-11 
MLG525 4-27 
EXFMT (execute format) statement 11-19 
exit application definition menu 
in DFU 
MLG110U 7-15 
MLG315U 8-11 
in query (MLG910Q) 8-50 
exit application key 8-15 
exit application prompt (DFU) 
in MLG110U 7-19 
in MLG315U 8-15 
extended field definition prompt in MLG110U 
(DFU) 7-11 


extension and line counter specifications 
(RPG) 

definition G-5 

MLG310 program 4-12 

MLG320 program 11-15 
externally described data files 4-5 


field reference file 
creating MLGREFP 6-25 
definition G-5 
summary of fields, MLGREFP C-1 
use 6-24, 6-37, 10-3 
field review prompt 
in MLG110U (DFU) 7-9 
in MLG9100 (query) 8-47 
fields, mailing list record 1-2 
file 
(see also data base file; data 
description specifications; 
device file; display file; 
field reference file; header file; 
inline data file; logical file; 
master file; physical file; source 
files: transaction files) 
definition G-5 
externally described 4-5 
in mailing list application 
INPUT (inline data) 3-2, 3-11, 4-9 
JOBFILP (job input) 9-3 
MLGENTL (transaction) 10-1 
MLGHDRP (header) 10-1 
MLGMASL (master) 4-26 
MLGMASP (master) 4-6, 9-7 
MLGMSTL 
(master) 6-30, 7-2, 8-1, 10-25, 11-1 
MLGMSTL2 (master) 8-34 
MLGMSTP 
(master) 6-30, 7-2, 8-1, 10-25, 11-1 
MLGREFP (field reference) 6-24, 10-3 
MLGTRNL (transaction) 6-33, 7-1 
MLGTRNP (transaction) 6-33, 7-1, 10-1 
MLGO35CD (display) 8-24, 8-31 
MLGO36CD (display) B-4 
MLG105D (display) 10-1 
MLG320D (display) 11-1 
QINLINE (inline data) 4-6 
source 6-11 
SOURCE (inline data) 3-6 
review of using 6-37 
file label (on diskette) 3-6 
file review prompt 
in DFU 
MLG110U 7-8 
MLG230U 8-37 
MLG315U 8-7 
in query (MLG910Q) 8-46 
fixed values, Commands using B-5 
formats (see record format) 
FRCRATIO parameter 2-13, 8-54, 10-27, 11-24 
functions, basic 2-2 
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general purpose library (QGPL) input specifications (RPG) (continued) 
definition G-6 MLG311 program 7-22 } 


in library list 6-7, 6-14, 6-16 MLG520 program 3-3 
use 6-2 MLG525 program 4-24 
general recovery considerations 2-13 input stream 
GRTOBJAUT (grant object authority) command, using 9-3 definition G-7 
use 


general 2-3 

to create file 4-6, 4-27 

to create program 3-6, 4-22, 4-25 

to execute program 3-11, 4-22, 4-27, 9-2 


inquiry 
header file MLGHDRP_ 10-1 comparison with query 8-43 
header record, batch 10-2 definition G-7 
heads down key entry. 10-12 using DFU application MLG230U 8-34 
how to use this publication 1-1 installing your system 2-9 


interactive data base utilities (IDU) 
definition G-7 
DFU 7-3, 8-3, 8-34 


query 8-43 
SDA 8-27 
SEU 5-6 
IBM-supplied interactive input 
libraries 6-2 and batch maintenance 
passwords 2-8 multiple work stations 10-1 
source files 5-6 single work station 7-1 
subsystems 2-6 and interactive maintenance 8-1, 11-1 
user profiles 2-8 interactive job 
IDU (see interactive data base utilities) concept 2-2 
immediate maintenance definition G-/7 
definition G-8 use 
use A-6, 8-34 maintenance of master file 8-1, 11-1 
incorrect data (see recovery transaction entry 7-1, 10-1 
considerations) interactive maintenance 8-1, 11-1 
indicators invoking 
auto dup /-18 DFU 7-5, 8-4 
auto Increment 7-18 DFU application 7-17, 8-13, 8-17, 8-20 
inline data file program (see calling program) 
definition G-6 query application 8-52 
INPUT query utility 8-44 
executing program MLG310 4-9 SDA 8-27 
executing program MLG520 13-2, 3-11 SEU 5-8, 6-17 
QINLINE (creating file MLGMASP) 4-6 
SOURCE (creating program MLG520) 3-9 
use 2-3, 2-4 
input 
batch 
and batch maintenance 4-1, 9-1 
in batch job 2-3 job 
definition G-6 batch (see batch job) 
diskette 3-1, 4-1, 9-1 description (see job description) 
interactive interactive (see interactive job) 
and batch maintenance 10-1 log (see job log) 
and interactive maintenance 8-1, 11-1 queue (see job queue) 
in interactive job 2-2 work station (see interactive job) 
spooling 2-3 JOB (job) command (/ /JOB) 
INPUT input file 3-2, 3-11, 4-9 examples (input stream) 
input queue (see job queue) creating file 4-6, 4-27 
input specifications (RPG) creating program 3-6, 3-8, 4-22 
definition G-/ executing program 3-11, 4-22, 9-2, 9-6 
MLG310 program 4-12 use 3-9, 9-2 





job description 
creating 6-14 
definition G-7 
mailing list application 6-14 
use 
in input stream 3-9 
on programmer menu 6-17, 7-24 
using data area for B-7 
job log 
definition G-7 
from MLG520 3-10 
printed 2-5 
job queue 
default 2-4 
definition G-8 
use 2-4, 3-9, 7-24 
job stream (see input stream) 
JOBD keyword 3-9 
JOBFILP file 9-3 


key field 4-2, 6-32 
keyboard template 7-4 
keyed sequence access path 
definition G-8 
description 4-2 
use 
example 4-3 
in DFU 7-3 
keywords (DDS) 
COLHDG 6-27 
EDTCDE 6-2/7, 10-3 
PFILE 4-26, 6-32, 6-36, 8-35, 10-6 
REF 6-30, 6-34, 10-16, 11-13 
RTNDTA 11-23 
SETOFF B-5, 11-13 
SFL 10-17 
SFLCTL 10-17 
SFLINZ, SFLPAG, SFLSIZ 10-17 
TEXT 6-27, 7-8 
UNIQUE 4-7, 6-32, 10-6 
UNLOCK 10-17 


label printing program (MLG520) 

creating 3-6 

description 3-2 

executing 3-11 
LASTTRN (last transaction format) 10-18 
level checking 

definition G-8 

use 4-25 


library 
an approach to using A-1 
concept 6-2 
definition G-8 
for mailing list application 6-10 
use In applications 6-1, 6-10 
library list 
default user 6-7, 6-8 
definition G-8 
program to set (SETLIBL) 6-16 
replacing 6-8, 6-16 
use (examples) 6-4 
use In applications 6-7 
listing of fields in field reference 
file C-1 
listing, compiler 
definition G-2 
printing 3-10 
logical file 
(see also data base file; data 
description specifications; master 
file; physical file; transaction file) 
concept 4-2 
creating 
MLGMASL 4-27 
MLGMSTL 6-32 
MLGMSTL2 8-35 
MLGTRNL 6-35 
definition G-8 
in batch maintenance approaches 
MLGENTL 10-6 
MLGMASL 4-31 
MLGMSTL 7-20, 10-25 
MLGTRNL 7-3 
in DFU application MLG110U 7-3 
in DFU application MLG230U 8-34 
in DFU application 
MLG315U 8-3, 8-17, 8-20 
in interactive maintenance approaches 
MLGMSTL 8-3, 8-17, 8-20, 11-1 
MLGMSTL2 8-34 
in RPG program MLG105_ 10-1 
in RPG program MLG311 7-20, 10-25 
in RPG program MLG320_ 11-1 
in RPG program MLG525 + 4-25, 4-26 
naming convention 1-5 
lowercase in SEU 6-27 


mailing label (sample) 3-4, 3-13 
mailing list application 
approaches 

batch input and batch maintenance 4-1 
batch maintenance of multiple diskette 
batches 9-1 
batch maintenance of multiple work 
station entries 10-1 
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mailing list application (continued) 
approaches (continued) 
interactive input and batch 
maintenance /-1 
interactive input and interactive 
maintenance 8-1 
interactive maintenance from multiple 
work stations 11-1 
relationship 1-8 
simple batch input (to print 
labels) 3-1 
summary 1-8 
defaults in examples 1-7 
files used in (see file) 
job description 6-14 
library 6-10 
naming rules and conventions 1-5 
record format 1-2 
system requirements 1-6 
using multiple libraries A-1 
using sertes of menus’ B-1 
mailing list clerk menu B-1, 8-22 
mailing list libraries 
MLGLIBBLD, MLGLIBPGM, MLGLIBOP, 
MLGLIBOP1 A-2 
MLGLIBDEV 6-10 
mailing list print program MLG525 
creating 4-25 
description 4-23 
executing 4-26 
maintenance 
batch 
with batch input 4-1 
with interactive input 7-1, 10-1 
concept 1-2 
immediate A-6, 8-34 
interactive 
with interactive input 8-1, 11-1 
online 8-3 
rebuild A-6 
inanual, using 
(see using this publication) 
master file 
(see also field reference file; header 
file; transaction file) 
creating 
MLGMASL 4-26 
MLGMASP 4-6 
MLGMSTL_ 6-32 
MLGMSTL2 8-35 
MLGMSTP_ 6-30 
DDS for (see data description 
specifications) 
in batch input/batch maintenance 
approaches 
MLGMASL 4-26 
MLGMASP 4-6, 9-7 
overview 4-1, 9-1 
summary 1-10, 1-16 


master file (continued) 

in DFU application MLG230U 
MLGMSTL2 8-34 
MLGMSTP 8-34 
overview 8-2 
Specifying 8-36 

in DFU application MLG315U 
MLGMSTL 8-3, 8-17, 8-20 
MLEMSTP 8-3, 3-17, 8-20 
overview 8-1 
specifying 8-6 

in interactive input/batch maintenance 

approaches 
MLGMSTL 7-20, 10-25 
MLGMSTP 7-20, 10-25 
overview /-1 
specifying in RPG 7-22 
summary 1-13, 1-19 

in interactive input/ interactive 

maintenance approaches 
MLGMSTL_ 8-3, 8-17, 8-20, 11-1 
MLGMSTL2 8-34 


MLGMSTP_ 8-3, 8-17, 8-20, 8-43, 11-1 


overview 8-1, 11-1 
specifying in DFU 8-6, 8-36 
specifying in query 8-45 
specifying in RPG 11-15 
summary 1-14, 1-20 
n query application MLG9100 
MLGMSTP 8-43 
overview 8-2 
specifying 8-45 
n RPG program MLG310 
MLGMASP_ 4-9, 9-7 
overview 4-1, 9-1 
specifying 4-11 
RPG program MLG311 
MLGMSTL 7-20 
MLGMSTP 7-20 
overview /-2 
specitying 7-22 
RPG program MLG320 
overview 11-1 
specifying 11-15 
n RPG program MLG525 
MLGMASP 4-23 
overview 4-1 
specifying 4-23 
maintenance of (concept) 1-3 
review of using 6-37 
use (general) 1-2, 6-30 
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member 
definition G-8 
examples 
MLGREFP 6-28 
MLG311 7-21 
in source files 5-7 
menu 


application-oriented (user) B-1, 8-22 
creating and using B-1, 8-20 
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menu (continued) 
definition G-8 
program call 8-16 
programmer (see programmer menu) 
system operator (see system operator 
menu) 
messages 
definition G-8 
displaying 
from program call menu 8-17 
from programmer menu 6-23 
monitoring for 9-4 
to indicate 
batch job submitted (SDA) 8-31, 8-32 
batch job submitted (user menu) B-6 
batch status 10-23 
empty diskette slot 9-4 
incorrect account number 11-5 
incorrect batch number 10-23 
incorrect option on menu 8-25 
member added 5-10 
no transaction record 10-24 
object already exists 6-21 
record changed 11-6 
MLGENTL transaction file (logical) 
(see also logical file; transaction file) 
DDS for 10-6 
specifying in MLG105 (RPG) 10-19 
use 10-1, 10-6, 10-25 
MLGHDRP header file (physical) 
(see also physical file) 
DDS for 10-4 
record format 10-2 
use 10-1, 10-4, 10-6, 10-25 
MLGHDRR record format 
fields, description of 10-2 
specifying in 
MLGENTL 10-6 
MLGHDRP_ 10-4 
MLGLK1 field 11-6 
MLGLST password 8-21 
MLGLSTCLRK user profile 8-21 
MLGMAINT diskette file 4-22 
MLGMASL master file (logical) 
(see also logical file; master file) 
creating 4-27 
DDS for 4-26 
specifying with override 4-27 
use 4-1, 4-26 
MLGMASP master file (physical) 
(see also master file; physical file) 
creating 4-6 
DDS for 4-7 
specifying in MLG310 (RPG) 4-11 
use 4-1, 4-11, 9-1 
MLGMASR record format 
fields, description of 1-2, 4-8 
specifying in 
MLGMASL 4-26 
MLGMASP 4-7 


MLGMSTL master file (logical) 


(see also master file) 

creating 6-32 

DDS for 6-32 

specifying in 
MLG311 (RPG) 7-22 
MLG315U (DFU) 8-6 
MLG320 (RPG) 11-15 

use 
batch maintenance 7-2, 7-20, 10-25 
general 6-30, 6-37 
interactive maintenance 8-1, 8-34, 11-1 
MLG311 (RPG) 7-2, 7-20 
MLG315U (DFU) 8-1, 8-3, 8-17, 8-20, 8-34 
MLG320 (RPG) 11-1 


MLGMSTL2 master file (logical) 


(see also logical file; master file) 
creating 8-35 

DDS for 8-35 

specifying in MLG230U (DFU) 8-36 
use 8-2, 8-34 


MLGMSTP master file (physical) 


(see also master file; physical file) 
creating 6-30 


DDS for 6-31 
specifying in MLG910Q (query) 8-45 
use 


batch maintenance 7-2, 7-20, 10-25 
general 6-30, 6-37 

interactive maintenance 8-1, 8-34, 11-1 
MLG910U (query) 8-43 


MLGMSTR record format 


fields, description of 1-2, 6-31 

specifying in 
MLGMSTL 6-32 
MLGMSTL2 8-35 
MLGMSTP_ 6-31 

use 
MLG230U (DFU) 8-37 
MLG315U (DFU) 8-7 
MLG9100 (query) 8-46 


MLGREFP field reference file 


(see also physical file) 
creating 6-25, 10-3 
DDS for 6-26, 10-3 
fields, description of 1-2, 4-8, 6-26, 
10-2 
referencing in 
MLGHDRP_ 10-4 
MLGMSTP_ 6-30 
MLGTRNP_ 6-34 
use 6-24, 6-37 


MLGTRNL transaction file (logical) 6-34 


(see also logical file; transaction file) 
creating 6-33 
DDS for 6-34 
specifying in 
MLG110U (DFU) 7-7 
MLG311 (RPG) 7-22 
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MLGTRNL transaction file (logical) (continued) 
use 
batch maintenance 7-1, 7-2, 7-20 
general 6-33, 6-37 
MLG110U (DFU) 7-1, 7-3, 7-7 
MLG311 (RPG) 7-20 
MLGTRNP transaction file (physical) 
(see also physical file: transaction 
file) 
creating 6-33 
DDS for 6-34 
use 
batch 
maintenance 7-1, 7-2, 7-20, 10-1, 10-25 
general 6-33, 6-37 
MLG110U (DFU) 7-1, 7-3, 7-7 
MLGTRNR record format 
fields, description of 4-8, 6-34 
specifying in 
MLGENTL 10-6 
MLGTRNL_ 6-36 
MLGTRNP_ 6-34 
use in MLG110U (DFU) 7-7 
MLGOOSC CL program (set application 
environment) 8-23 
(see also program) 
MLGO35C CL program (display menu) 
(see also program) 
calling from MLGOO5C 8-23 
creating 
directly from source 8-26 
through SDA 8-32 
display file for 8-24 
use 8-1, 8-20, 8-26 
MLGO35CD display file 
(see also display file) 
creating 
directly from DDS 8-24 
through SDA 8-31 
DDS for 8-24 
declaring in MLGO35C (CL) 8-26 
use 8-20, 8-24 
MLGO36C CL program (display menu to submit 
batch) B-5 
MLGO36CD display file B-4 
MLG105 RPG program (transaction entry) 
(see also program) 
display file for 10-13 
executing 10-7 
program flow 10-7 
specifications for 10-19 
use 10-1, 10-10, 10-17, 10-22 
MLG105D display file 
(see also display file) 
DDS for 10-13 
specifying in MLG105 (RPG) 10-19 
use 10-1, 10-16 
MLG110U DFU application (transaction entry) 
(see also DFU displays) 
creating 7-4 


MLG110U DFU application (transaction entry) (continued) 
executing 7-17 
use 7-1, 7-3, 7-18 
MLG230U DFU application (inquiry) 
(see also DFU displays) 
creating 8-36 
executing 8-40 
use 8-2, 8-34, 8-40 
MLG310 RPG program (batch maintenance) 
(see also program) 
creating 4-22 
executing 4-22 
program flow 4-15 
specifications for 4-11 
use 4-1, 4-9, 9-1, 9-7 
MLG311 RPG program (batch maintenance) 
(see also program) 
creating 7-20 
executing 7-23 
specifications for 7-22 
use 7-2, 7-20, 10-25 
MLG315C CL program (execute application) 
(see also program) 
creating 8-18 
executing 8-19 
use 8-17, 8-19 
MLG315U DFU application (interactive 
maintenance) 
(see also DFU displays) 
creating 8-4 
executing 
directly 8-13 
from CL program 8-17 
from user menu 8-23 
sample output 8-16 
use 8-1, 8-3, 8-14 
MLG320 RPG program (interactive 
maintenance) 
(see also program) 
alternative solution 11-23 
display file for 11-9 
executing 11-2 
program flow 11-2 
sample output 11-6, 11-7 
specifications for 11-14 
use 11-1, 11-5 
MLG320D display file 
(see also display file) 
DDS for 11-9 
specifying in MLG320 (RPG) 11-15 
use 11-1, 11-13 
MLG520 RPG program (label printing) 
(see also program) 
creating 3-6 
executing 3-11 
specifications for 3-2 
use 3-1, 3-2 
MLG525 RPG program (mailing list print) 
(see also program) 
creating 4-25 
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MLG525 RPG program (mailing list print) (continued) 
executing 4-26 
specifications for 4-23 
use 4-1, 4-23 
MLG9100 query application 
(see also query displays) 
creating 8-44 
executing 8-52 
sample output 8-53 
use 8-2, 8-43 
MONMSG (monitor message) command, 
using 9-4 
multiple access paths 8-34 
multiple diskette batches (input) 9-1 
multiple work stations, interactive 
maintenance from 11-1 


name (object), qualified 6-3, 6-11 
name and zip code access paths 8-34 
naming rules and conventions 1-4 


offline device 1-6, 3-6 
online backup A-8 
online maintenance 8-3 
operations, daily 2-9 
Output 
definition G-9 
printed (see printed output) 
spooling 2-3 
output queue 
default 2-5 
definition G-9 
specifying when starting 
writer 2-12 
use 2-5, 3-2, 3-10, 3-12 
output specification prompt (query) 8-46 
output specifications (RPG) 
definition G-9 
MLG105 program 10-24 
MLG310 program 4-19 
MLG320 program 11-21 
MLG520 program 3-4 
MLG525 program 4-24 
Overview of 
application approaches 
all approaches (Summary) 1-8 
batch input and batch maintenance 4-1 
batch maintenance of multiple diskette 
batches 9-1 
batch maintenance of multiple work 
station entries 10-1 


overview of (continued) 
application approaches (continued) 
interactive input and batch 
maintenance 7-1 
interactive input and interactive 
maintenance 8-1 
interactive maintenance from multiple 
work stations 11-1 
simple batch input 3-1 
mailing list application 1-2 
publication 1-1 
OVRDBF (override with data base file) 
command 
examples B-9, B-11, 4-27 
use 4-23, 4-26, 4-27 
OVRDKTF (override with diskette file) 
command, using 9-4 


password 
creating 8-21 
definition G-10 
for mailing list clerk 8-21 
IBM-supplied 2-8 
use 2-8 
paths, access (see access paths) 
PFILE keyword 4-26, 6-32, 6-36, 8-35, 10-6 
PGM (program) command 
examples (CL 
program) B-5, B-9, B-11, 6-18, 8-18, 8-23 
examples (CL program) 8-26 
use 6-18 
PGMR password 2-8 
physical file 
(see also data base file; data 
description specifications; header 
file; logical file; master file; 
physical file; source files; 
transaction file) 
concept 4-2 
creating 
MLGMASP 4-6 
MLGMSTP_ 6-30 
MLGREFP 6-25 
MLGTRNP_ 6-33 
source files 6-11 
definition G-10 
in batch maintenance approaches 
JOBFILP 9-3 
MLGHDRP_ 10-4 
MLGMASP_ 4-6, 9-7 
MLGMSTP 7-20, 10-25 
MLGTRNP 7-3, 7-7, 7-20, 10-5 
in interactive maintenance 
approaches’ 8-3, 8-17, 8-20, 11-1 
in query application MLG910Q 8-43 
in RPG program MLG310 4-9, 9-7 
in RPG program MLG525 4-23 
naming convention 1-5 
placing jobs on job queue 2-4 
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powering down 2-12 
print program 
mailing labels (MLG520) 3-2 
mailing list (MLG525) 4-23 
printed output 
description 2-5 
for MLG310 (RPG batch maintenance 
program) 4-21 
for MLG315U (DFU application) 8-16 
for MLG320 (RPG interactive maintenance 
program) 11-6, 11-7 
for MLG520 (RPG label printing 
program) 3-4, 3-13 
for MLG910Q (query application) 8-53 
printer (IBM 5211, 3262, 3203) 1-6 
printer/display layout 
MLG310 4-21 
MLG520 3-4 
printer file 
definition G-10 
use of 2-5 
printer writer, starting 2-12 
procedures, daily 2-9 
production 
data A-6 
libraries A-/ 
products required, program 1-6 
program 
(see also data file utility; CL 
program; query utility; RPG program) 
calling (see calling program) 
creating (compiling) 
from diskette source 3-6 
from online (SEU) source 6-16 
definition G-10 
in mailing list application 
DSKTCPY (CL) 9-4 
MLGOOSC (CL) 8-23 
MLGO35C (CL) 8-26 
MLGO36C (CL) B-5 
MLG105 (RPG) 10-7 
MLG310 (RPG) 4-9 
MLG311 (RPG) 7-20 
MLG315C (CL) 8-18 
MLG320 (RPG) 11-2 
MLG520 (RPG) 3-2 
MLG525 (RPG) 4-23 
SETLIBL (CL) 6-16 
using SEU to enter source 5-6 
program call menu 8-16 
program cycle (RPG) 
definition G-10 
use (examples) 3-2, 4-23 
program flow for 
MLG105 (transaction entry) 10-7 
MLG310 (batch maintenance) 4-15 
MLG320 (interactive maintenance) 11-2 
program for displaying a menu’ B-5, 8-26 
program products required 1-6 


programmer 
development and administrative A-1 
use of a work station 5-1 
programmer menu 
as working display 5-2 
considerations 6-20 


options, required entries for 5-2, 5-8, 6-17, 6-19 
prompting, requesting 5-4 
using to 


call program 6-20, 7-23 
clear transaction file 7-25 
create field reference file 6-25 
create job description 6-14 
create job file 9-3 
create library 6-10 
create master files 6-30 
create program 6-16, 6-21, 8-18 
create source files 6-11 
create transaction files 6-33 
display library list 6-7 
display messages 6-23 
display submitted jobs 6-23 
execute DFU application 7-17, 8-13 
execute query application 8-52 
replace existing object 6-22 
replace library list 6-16 
request DFU 7-5, 8-4 
request query 8-44 
request SDA 8-27 
request SEU 5-8 
submit batch job 7-24, 8-52 
programming considerations for 
creating user profiles 8-22 
library MLGLIBPGM A-8 
MLG105 10-26 
MLG110U and MLG311 7-27 
MLG230U 8-42 
MLG315C 8-20 
PROMPT format 11-13 
prompting, command 5-4 
publication, using (see using this 
publication) 
PWRDWNSYS (power down system) command, 
using 2-12 


QBATCH job description 3-9 

QBATCH job queue 2-4, 3-9, 7-24 
QBATCH subsystem 2-6 

QCALLMENU (program call menu) 8-16 
QCTL subsystem 2-6 

QGPL library (see general purpose library) 
QIDU library 6-2, 6-8, 6-14, 6-16 
QINTER subsystem 2-6 

QPGMR user profile 2-8 

QPRINT output file 2-5, 3-2, 3-3, 3-5, 3-13 











QPRINT output queue 2-5, 2-12, 3-2, 3-13 
QRPG library 6-2, 6-8, 6-14, 6-16 
QRYDTA (query data) command, using 8-52 
QSECOFR user profile 2-8 
QSPL subsystem 2-6 
QSYSOPR user profile 2-8 
QSYSPRT device 2-12 
QTEMP library (see temporary library) 
qualified name 6-3, 6-11 
query displays 
application creation prompt 8-51 
exit application definition menu 8-50 
field review prompt 8-47 
file review prompt 8-46 
output specification prompt 8-46 
query create/change menu 8-45 
query create prompt 8-45 
query definition prompt 8-47, 8-48 
query menu 8-44 
selection test prompt 8-49 
sort specification prompt 8-50 
query utility 
(see also query displays) 
application program MLG9100 
creating 8-44 
executing 8-52 
sample output 8-53 
definition G-11 
use 8-43 
queue (see job queue; output queue) 
QUSER user profile 2-8 


RCVDTAARA (receive data area) command, 
using B-/7 
reader 
data base 9-4, 9-6 
definition G-11 
diskette 3-7, 3-10, 3-11, 4-6, 4-22, 4-27 
Starting 3-7 
use 2-3, 3-7 
reading data from 
inultiple diskettes 9-2 
single diskette 3-7 
reading diskettes 3-7 
rebuild maintenance 
definition G-11 
use A-6 
record format 
ADDTN, DSPLY (display) 11-14 
CHANGE, PROMPT (display) 11-13 
CONFIRM (display) 10-17 
definition G-11 
INITIAL (display) 10-16 
LASTTRN (display) 10-18 
MENU (display) B-4, 8-24 


record format (continued) 
MLGHDRR (header) 
fields, description of 10-2 
in MLGENTL 10-6 
in MLGHDRP_ 10-4 
MLGMASR (master) 
fields, description of 1-2 
in MLGMASL 4-26 
in MLGMASP_ 4-7 
MLGMSTR (master) 
fields, description of 1-2, 6-31 
in DFU application MLG230U 8-37 
n DFU application MLG315U 8-7 
n logical file MLGMSTL 6-34 
n logical file MLGMSTL2 8-35 
n physical file MLGMSTP- 6-31 
IN query application MLG9100 8-49 
MLGTRNR (transaction) 
fields, description of 4-8, 6-34 
in DFU application 
MLG110U 7-8, 7-10, 7-12 
in logical file MLGENTL 10-6 
in logical file MLGTRNL 6-36 
in physical file MLGTRNP 6-34 
SUBFIL, SUBCTL (display) 10-17 
record, batch header 10-2 
record, mailing list 1-2 
records, transaction (see transaction 
records) 
recovery considerations 
for batch input and batch 
maintenance 4-28, 9-7 
for interactive input and batch 
maintenance 
from multiple work stations 10-27 
from single work station 7-26 
for interactive input and interactive 
maintenance 8-54, 11-24 
for simple batch input (to print 
labels) 3-14 
general 2-13 
using save/restore 2-13 
REF keyword 6-30, 6-34, 10-16, 11-13 
reference file, field 6-24, 10-3 
references vi 
replace library list program 
(SETLIBL) 6-16 
replacing library list 6-8, 6-16 
request data 
definition G-11 
example (SBMJOB command) B-5 
use (SBMJOB command) B-6 
requirements, system 1-6 
requirements, typical DP application 1-3 
RETURN (return) command, using B-2, B-5 
review of files and their usage 6-37 
RPG program 
(see also specifications for RPG 
programs) 
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RPG program (continued) 
calling (executing) 
from diskette input 3-11 
from work station 7-23 
creating 
from diskette source 3-6 
from work station 7-20 
MLG105 (transaction entry) 10-7 
MLG310 (batch maintenance) 4-9 
MLG311 (batch maintenance) 7-20 
MLG320 (interactive maintenance) 11-2 
MLG520 (label printing) 3-2 
MLG525 (mailing list print) 4-23 
using SEU to enter source 5-6 
RPLLIBL (replace library list) command, 
using A-3, 6-9, 6-16 
ROSDTA parameter (see request data) 
RTNDTA keyword 11-23 
rules, naming 1-4 
RVKOBJAUT (revoke object authority) 
command, using A-3 


samples (see examples) 
save/restore in recovery 2-13 
SBMJOB (submit job) command 
examples B-5, B-10 
use B-6 
screen (see display) 
screen design aid (SDA) 
definition G-12 
use in creating menu 8-2/7 
SDA (see screen design aid) 
SDA displays 
CL save/create CL program 8-32 
initial menu definition 8-28 
menu definition 8-28 
option menu 8-27 
save DDS/create display device 
file 8-31 
SECOFR password 2-8 
select /omit 
definition G-12 
logical file MLGMASL 4-26 
query application MLG910U 8-49 
selection criteria 4-2, 4-27 
selection test prompt (query) 8-49 
sending messages (program call menu) 8-17 
series of menus’ B-1 
SETLIBL (set library list) program 6-16 
SETOFF keyword B-5, 11-13 
SEU (see source entry utility) 
SEU displays 
edit 5-10, 5-11, 5-15, 6-18, 8-18 
exit 5-12, 5-16 
member list 5-14 
SFL keyword 10-17 


SFLCTL keyword 10-17 
SFLINZ, SFLPAG, SFLSIZ keyword 10-17 
sign off 
definition G-12 
in interactive job 2-2 
sign-on 
definition G-12 
for production users A-6 
in interactive job 2-2 
procedure 2-9 
to get application-oriented menu 8-25 
to get program call menu 8-19 
SIGNOFF (sign off) command, using B-5, 
8-23, 8-28 
SNDRCVF (send receive file) command, 
using B-5, 8-26 
sort specification prompt (query) 8-50 
SOURCE diskette label 3-6, 3-8 
source entry utility 
adding (creating) source 5-9 
changing source 5-13, 6-20 
creating files 6-25 
creating program 6-16 
definition G-12 
exiting 5-12 
invoking (requesting) 5-9, 6-16, 6-25 
uppercase/lowercase 6-27 
use (general) 5-7 
SOURCE file (in MLG520) 3-9 
source files 
creating 
QCLSRC_ 6-11 
QDDSSRC_ 6-12 
QRPGSRC_ 6-12 
QUDSSRC_ 6-13 
definition G-12 
example 5-7 
IBM-supplied 5-6 
in mailing list application 6-11 
source listing 
definition G-12 
printed from compile 3-10 
source member 
definition G-12 
description 5-7 
examples 
MLGREFP 6-28 
MLG311 7-21 
source statements 
definition G-13 
examples 
diskette input 3-6 
work station input (SEU) 5-11, 5-15, 
6-18, 8-18 
source, RPG lil, as input stream 3-6 
Specifications for RPG programs 
(see also RPG program) 
MLG105 10-19 
MLG310 4-11 
MLG311 7-22 





specifications for RPG programs (continued) 
MLG320 11-15 
MLG520 3-2 
MLG525 4-23 
spooled output file 
definition G-13 
use 2-5 
spooling 
definition G-13 
inline data files 2-3, 3-6 
use (general) 2-3 
spooling subsystem (QSPL) 
definition G-13 
use 2-6 
starting CPF 2-10 
STRDBRDR (start data base reader) command, using 9-4 
STRDKTRDR (start diskette reader) command, using 3-7, 3- 
STRPRTWTR (start printer writer) command, 
using 2-12, 3-10 
STRSBS (start subsystem) command, 
using 2-11 
SUBCTL (subfile control format) 10-17 
SUBFIL (subfile format) 10-17 


subfile 
definition G-13 
use 10-11 


submitting batch jobs from menu 
application-oriented menu B-3 
programmer menu 7-24, 8-52 
Subroutine 4-16 
subsystems 
definition G-13 
IBM-supplied 2-6 
use of 2-7 
SYSOPR password 2-8 
system failure (see recovery 
considerations) 
system operator menu 
use (general) 2-11 
use to 
call program (DSKTCPY) 9-4 
Start diskette reader 3-7 
start printer writer 2-12 
start subsystem 2-11 
system requirements 1-6 
system, installing your 2-9 


temporary library (QTEMP) 

definition G-14 

in library list 6-7, 6-14, 6-16 
terminal (IBM 5251 display station) 1-6 
terminating (powering down) system 2-12 
TEXT keyword 6-27, 7-8 
time and date, current 2-10 


transaction entry program MLG105_ 10-1 
transaction file 


(see also field reference file; header 
file; master file) 
creating 
MLGTRNL_ 6-35 
MLGTRNP 6-33 
DDS for (see data description 
specifications) 
in DFU application MLG110U 
MLGTRNL 7-3, 7-7 
MLGTRNP 7-3, 7-7 
overview 7-1 
specifying 7-7 
in interactive input/batch maintenance 
approaches 
MLGENTL 10-6 
MLGTRNL 7-3, 7-7, 7-20 
MLGTRNP 7-3, 7-7, 7-20, 10-5 
overview 7-1, 10-1, 10-25 
in RPG program MLG105 
overview 10-1 
specifying 10-19 
in RPG program MLG311 
overview 7-2, 7-20 
specifying 7-22 
review of using 6-37 
use (general) 6-33 
transaction number 7-12 
transaction records (RPG maintenance 
program MLG310} 4-8 
transaction, definition of G-14 
transactions from multiple users 10-1, 
11-1 
type of account field 1-2, 4-8 


wd 


UDS (see utility definition specification) 
UNIQUE keyword 4-7, 6-32, 10-6 
UNLOCK keyword 10-17 
update (see maintenance) 
use 03-012 
user menu B-1, 8-22 
USER password 2-8 
user profile 
creating 2-8, 8-21 
definition G-14 
for mailing list clerk 8-20 
IBM-supplied 2-8 
use 2-8 
using a work station (for programmer) 5-1 
using additional mailing list 
libraries A-6 
using CL program to execute DFU 
application 8-17 
using files 6-24 


Index X-17 


using menus’ B-1 
(see alSo application-oriented menu, 
program call menu, 
programmer menu, system 
operator menu) 
using this publication 
conventions v 
defaults, use of 1-7 
for more information — vi 
how to use 1-1 
organization v, 1-8 
purpose v 
what you should know vi 
using transaction records (see transaction 
records) 
utilities (see interactive data base 
utilities) 
utility definition specification (UDS) 
definition G-14 
use in DFU 7-15 


validity check prompt in MLG315U 

(DFU) 8-9 

variable 
CL programs using B-2, B-5, B-9, B-10, 8-26 
definition G-14 


work station 

definition G-14 

programmer menu (see programmer menu) 

programmer use of 5-1 
work station (IBM 5251 display 
station) 1-6, 5-1 
work station file (see display file) 
working display 

definition G-14 

using programmer menu as_ 5-2 
writer 

definition G-14 

Starting printer 2-12 

use 2-3, 3-10 


3203 printer, IBM 1-6 

3262 printer, IBM 1-6 

5211 printer, IBM 1-6 

5251 display station, IBM 1-6 

5280 distributed data system, IBM_ 1-6, 3-6 
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